On Fri, Feb 11, 2011 at 2:31 PM, Soren Hansen <so...@ubuntu.com> wrote:
> 2011/2/11 Jay Pipes <jaypi...@gmail.com>:
>> On Thu, Feb 10, 2011 at 7:21 PM, Brian Schott <bfsch...@gmail.com> 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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
