openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxx>]

2011/2/11 Jay Pipes <jaypipes@xxxxxxxxx>:
> On Fri, Feb 11, 2011 at 2:31 PM, Soren Hansen <soren@xxxxxxxxxx> wrote:
>> 2011/2/11 Jay Pipes <jaypipes@xxxxxxxxx>:
>>> Just to make something clear, the EC2 API has nothing to do with the
>>> -t flag.
>> Sorry, what? It's passed verbatim in the EC2 RunInstances API call:
>>   http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/index.html?ApiReference-query-RunInstances.html
>>
>> ..so it's certainly part of the API.
> No. The -t flag is part of the eucatools CLI program, that's all I was
> saying. The instanceType xs:string element is what's part of the EC2
> API.

I don't think I understand why this distinction is useful? Of course
the -t is an option to the cli tools, but it gets turned into a query
parameter, that ends up verbatim in the EC2 API controller in Nova.

>>> That is specific to the eucatools (or ec2 CLI tools).  The
>>> request that goes through to the EC2 API controller (in nova, this is
>>> nova.api.ec2.cloud.CloudController), passing to the controller an XML
>>> packet that has a variety of fields that the controller then looks for
>>> in populating the database with information about the instance to spin
>>> up.
>> This doesn't sound familiar at all. Can you provide a reference to any of this?
> Sure. Here's the code from the file referenced above:
>
>    def run_instances(self, context, **kwargs):
>        max_count = int(kwargs.get('max_count', 1))
>        instances = self.compute_api.create(context,
>            instance_type=instance_types.get_by_type(
>                kwargs.get('instance_type', None)),
> <snip>
>
> The XML from the client request has already been deserialized and the
> **kwargs contains the fields that were in the XML request to the API
> controller, right?

Well, no, we don't actually accept XML. We accept query parameters.
The SOAP API is not (yet) supported. Other than that, yes, you are
correct.

> The code:
>
> instance_types.get_by_type(kwargs.get('instance_type', None))
>
> would blow up with the suggested "let's just tack everything on to the
> -t flag" solution.

Um, sure :)  I don't think anyone was suggesting that if we pass extra
stuff as part of the instanceType attribute it would magically just
work and apply the requested restrictions and whatever. Of course we'd
need to detect these extra bits and handle them somehow. Probably very
much like how we currently let people specify "<access_key>:<project>"
as their access key as a way to denote the project to which their
request pertains.

>>> Tacking on something to the -t flag would be a total hack that
>>> wouldn't be particularly future-proof.
>> Actually, given the limitations the EC2 imposes, I think it's actually a pretty
>> good idea. I can't think of a better way to attempt to expose this in
>> the EC2 API.
> Please read more of the emails in this thread. We're discussing not
> just imageType, but:
>
> * Allowing a client request to contain arbitrary attributes that can
> be passed to schedulers and other workers to help them do their work
> more intelligently; specifically, request attributes that allow a
> scheduler to place an instance or volume "near" something in a zone.

You've clearly thought about this more than I. Which parts of that is
it that can't possibly be expressed as a string appended to the
instance_type in the EC2 API?

> * Not JUST the EC2 API, but the OpenStack API, too. We need a solution for both.

Oh, sure, sure. For the OpenStack API I'm sure we would use something
that's actually sane. The instance_type hack would just be a hack for
the EC2 side of things.

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/