I'd suggest something lispy for encoding this. (and (>= cpu 1) (= arch x86) )
On Mon, Nov 16, 2009 at 8:00 AM, Adrian Cole adrian@jclouds.org wrote:
Well, encoding the query value can work, but is ugly to look at. Ex, lots of clouds already require encoding of query values when used for arbitrary metadata. Are request headers a no-no?
-Adrian
On Mon, Nov 16, 2009 at 7:54 AM, Bob McWhirter bmcwhirt@redhat.com wrote:
Yah, I think you've got it.
This also opens up the "query" can of worms. We have a few queryable things at the moment, but mostly by equality on an ID or a few other select attributes. Really more of a filter than a query.
Now we're talking about an entire model that involves ranges and relative comparison.
Does anyone have any prior art on how complex queries can be encoded in a RESTful query-string?
?arch=x86
is fairly simple, but...
?memory>2gb
is just invalid.
This is still retrieving a collection, so should be a GET operation. So, we can't POST a <query> XML document. I don't think we need to support complex boolean expressions in the API. But even just "at least 12gb" needs to be encodable in a URL format.
Thoughts?
-Bob
On Nov 16, 2009, at 10:46 AM, Adrian Cole wrote:
so are we talking something like the following, or am I too much of a deltanoob?
(ignoring other details such as image type)
service = deltaCloud:service(ec2) instance = service:instance(1Cpu) profile = profile service: lookup minimum profile that has 1Cpu return instantiate(profile)
similarly with options
instance = deltaCloud:instance(1Cpu, resizable) profile = deltaCloud:profile service: lookup minimum profile that has 1Cpu and is resizable service = deltaCloud:service(profile) return service.instantiate(profile)
On Mon, Nov 16, 2009 at 6:31 AM, Bob McWhirter bmcwhirt@redhat.com wrote:
Would they get the attributes similar to what you have below?
Yah, everything that 'flavor' has at the moment, plus I think we need to add some measure of CPU. I don't know if we need to specify more details than "# of CPU units" or "# of cores". Intel vs AMD, speed, etc, might be more than we can attack for now.
This would also be a place to specify the number of network interfaces available, perhaps, or other special requirements of the virtual hardware you might need.
These would specify the different profiles available, in terms of min/ max capabilities for each profile.
For a cloud provider with completely flexible instances, it might have 1 profile something akin to
memory: 0GB-64GB, default=2gb disk: 0GB-1TB, default=200gb cpu: 1-8, default=2
For something like EC2, min==max, and it'd have a profile per instance type.
Upon instantiating an instance from an image, you'd select, and optionally parameterize a hardware profile for the instance. EC2, no parameterization/customization is possible. For RIMU etc, you could feed it what you want.
We may also need a flag indicating mutability of the hardware post- launch, in case a provider allows adding CPU/disk/RAM on-the-fly.
Yes, the profile becomes more an attribute of the instance as opposed to a parent (which is how I tended to think about it).
-- bk
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel