openstack team mailing list archive

[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. 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