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. 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. Tacking on something to the -t flag would be a total hack that wouldn't be particularly future-proof. 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 root of the problem here, though, is how can the clients that request new instances be spun up (or volumes be attached) send a set of custom attributes that define the requirements that the request entails? There are many, many attributes that should be able to attach to a request: * What zone the instance/volume should be in * What zone(s) the instance/volume should be *near* * What hardware/architecture the instance should be placed on * What service-level agreement a zone or group of volumes should be running under etc, etc. We need to figure out a way of sending this type of request data without a) breaking the existing API, and b) allows the scheduler nodes to route requests more intelligently by looking at these additional attributes of the request from the client. My initial thought is to make a simple Middleware class whose only purpose is to look for certain fields in the HTTP request body or headers (client_request?) and place those attributes in the wsgi environ mapping so that middleware further down the "pipe" (such as the Scheduler controllers) can easily pull this data out and more intelligently route client requests to the zone scheduler controllers that meet the requirements sent from the client. -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
