openstack team mailing list archive

[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>:
>> On Thu, Feb 10, 2011 at 7:21 PM, Brian Schott <bfschott@xxxxxxxxx> wrote:
>>> Justin,
>>>
>>> Our USC-ISI team is very interested in this.  We are implementing different architecture types beyond x86_64.  We are also interested in suggesting switch topology for MPI cluster jobs, passing in requests for GPU accelerators, etc.  Currently, our approach has been to specify these through instance_types. What you describe is more flexible, but I wonder if for EC2 api we could stretch the -t flag.
>>
>> 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.

>> 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?

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.

>> 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.
* Not JUST the EC2 API, but the OpenStack API, too. We need a solution for both.

>> I think that perhaps the user_data field in the XML might be a better
>> choice, since this has a more free-form capacity than a very specific
>> instance_type code that the EC2 API controller looks for.
>
> The user-data field is used by the user to pass information through to
> the instance. It's typically used for post-boot configuration of sorts
> for the VM's. If we steal it for this purpose, we lose the ability to
> pass stuff this way.

K, fair enough, thanks for the details on user_data. Appreciated, and
now that I know this, you are right that user_data doesn't seem to be
the right fit...

-jay