openstack team mailing list archive
Mailing list archive
Re: Allowing clients to pass capability requests through tags?
On Feb 11, 2011, at 2:41 PM, Jay Pipes wrote:
> 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
Correct, but eucatools allows arbitrary strings.
> 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,
> kwargs.get('instance_type', None)),
> 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.
I'm not a great python coder, but in instance_types.get_by_type(), I'd parse the entire string, and create a dictionary object with the base fields memory_mb..., plus any additional fields "cpu_arch" that got passed in.
run-instances -t "m1.small;near_volume='v1234'" ...
dict(memory_mb=2048, vcpus=1, local_gb=20, flavorid=2, near_volume='v1234')
> 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.
It looks like the same fields could be pulled from <metadata> easily enough and result in the same object getting passed around, but that's outside my experience.
<meta key="My Server Name">Apache1</meta>