Howdy folks--
Been thinking about the flavor/hardware problem some, and he's my initial thoughts:
We should remove "flavors" as they exist now, and replace them with "hardware profiles" (or some other name).
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.
Thoughts?
-Bob
On 11/16/2009 09:06 AM, Bob McWhirter wrote:
Howdy folks--
Been thinking about the flavor/hardware problem some, and he's my initial thoughts:
We should remove "flavors" as they exist now, and replace them with "hardware profiles" (or some other name).
Would they get the attributes similar to what you have below?
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
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
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
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=2For 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
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
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
Lots of emails while I was asleep! I
2009/11/17 Bob McWhirter bmcwhirt@redhat.com:
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
We do it similar things using matrix params. Query /orders;inactive=N, or /orders;inactive=N;name=blah;host=host76
Could have ;arch=x86;min_mem=2b;min_cpu=2
I guess we use it to filter out a subset of the resource,
I don't know if this is the right way for this, thats just how we do it :)
-Ivan, rimuhosting.com
I like that, in that it turns relativistic query terms into equalties/ assignments.
Instead of
memory > 2gb
that implies, as you've pointed out
minimum_memory=2gb
Which encodes into URLs nicely.
Thanks!
-Bob
On Nov 16, 2009, at 1:48 PM, Ivan Meredith wrote:
Lots of emails while I was asleep! I
2009/11/17 Bob McWhirter bmcwhirt@redhat.com:
Does anyone have any prior art on how complex queries can be encoded in a RESTful query-string?
?arch=x86is fairly simple, but...
?memory>2gbWe do it similar things using matrix params. Query /orders;inactive=N, or /orders;inactive=N;name=blah;host=host76
Could have ;arch=x86;min_mem=2b;min_cpu=2
I guess we use it to filter out a subset of the resource,
I don't know if this is the right way for this, thats just how we do it :)
-Ivan, rimuhosting.com
good idea.. One thought: as opposed to supporting less than greater than, we could say we only support equals and at least.
That limits the association to 2 types, which we could (in a hackish way) encode using the two common request parameter types:
query is for squishy matrix is for must be
ex. ;arch=x86?mem=2?core=2
arch must be x86, but I can use anything with at least 2g memory and 2 cores
pros are that we do not need to invent something we'd need to encode, and don't need to parse parameter names.
cons is that the thing is a little weird
wdyt?
On Mon, Nov 16, 2009 at 10:48 AM, Ivan Meredith ivan@ivan.net.nz wrote:
Lots of emails while I was asleep! I
2009/11/17 Bob McWhirter bmcwhirt@redhat.com:
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
We do it similar things using matrix params. Query /orders;inactive=N, or /orders;inactive=N;name=blah;host=host76
Could have ;arch=x86;min_mem=2b;min_cpu=2
I guess we use it to filter out a subset of the resource,
I don't know if this is the right way for this, thats just how we do it :)
-Ivan, rimuhosting.com
2009/11/17 Adrian Cole adrian@jclouds.org:
good idea.. One thought: as opposed to supporting less than greater than, we could say we only support equals and at least.
That limits the association to 2 types, which we could (in a hackish way) encode using the two common request parameter types:
query is for squishy matrix is for must be
ex. ;arch=x86?mem=2?core=2
arch must be x86, but I can use anything with at least 2g memory and 2 cores
pros are that we do not need to invent something we'd need to encode, and don't need to parse parameter names.
cons is that the thing is a little weird
wdyt?
I personally think that just using matrix params for this is best. I have no real reason, i just see it as less complicated.
personally i see...
no arch = any ;arch=x86 ;arch=x86|x64
I agree matrix are more state oriented then query.
so, where we are at is:
thing
;thing=this ;thing=this|that ;min_thing=this
the only one I can see us improving is the last, but not extremely important if we can't.
Cheers, -Adrian
On Mon, Nov 16, 2009 at 11:36 AM, Ivan Meredith ivan@ivan.net.nz wrote:
2009/11/17 Adrian Cole adrian@jclouds.org:
good idea.. One thought: as opposed to supporting less than greater than, we could say we only support equals and at least.
That limits the association to 2 types, which we could (in a hackish way) encode using the two common request parameter types:
query is for squishy matrix is for must be
ex. ;arch=x86?mem=2?core=2
arch must be x86, but I can use anything with at least 2g memory and 2 cores
pros are that we do not need to invent something we'd need to encode, and don't need to parse parameter names.
cons is that the thing is a little weird
wdyt?
I personally think that just using matrix params for this is best. I have no real reason, i just see it as less complicated.
personally i see...
no arch = any ;arch=x86 ;arch=x86|x64
and what's about network's for security reasones and storagetypes for iospeed inside a private and public cloud? I think, if deltacloud knows about this information from a cloud provider there are other profile information very useful for system or platform creation.
This are more network profiles and storage profiles ?
Thomas
On 16.11.2009, at 20:41, Adrian Cole wrote:
I agree matrix are more state oriented then query.
so, where we are at is:
thing
;thing=this ;thing=this|that ;min_thing=this
the only one I can see us improving is the last, but not extremely important if we can't.
Cheers, -Adrian
On Mon, Nov 16, 2009 at 11:36 AM, Ivan Meredith ivan@ivan.net.nz wrote:
2009/11/17 Adrian Cole adrian@jclouds.org:
good idea.. One thought: as opposed to supporting less than greater than, we could say we only support equals and at least.
That limits the association to 2 types, which we could (in a hackish way) encode using the two common request parameter types:
query is for squishy matrix is for must be
ex. ;arch=x86?mem=2?core=2
arch must be x86, but I can use anything with at least 2g memory and 2 cores
pros are that we do not need to invent something we'd need to encode, and don't need to parse parameter names.
cons is that the thing is a little weird
wdyt?
I personally think that just using matrix params for this is best. I have no real reason, i just see it as less complicated.
personally i see...
no arch = any ;arch=x86 ;arch=x86|x64
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
+1 for extensible attrs such as innetwork, storageclass
On Mon, Nov 16, 2009 at 11:56 AM, Thomas von Steiger thomas.vonsteiger@bluewin.ch wrote:
and what's about network's for security reasones and storagetypes for iospeed inside a private and public cloud? I think, if deltacloud knows about this information from a cloud provider there are other profile information very useful for system or platform creation.
This are more network profiles and storage profiles ?
Thomas
On 16.11.2009, at 20:41, Adrian Cole wrote:
I agree matrix are more state oriented then query.
so, where we are at is:
thing
;thing=this ;thing=this|that ;min_thing=this
the only one I can see us improving is the last, but not extremely important if we can't.
Cheers, -Adrian
On Mon, Nov 16, 2009 at 11:36 AM, Ivan Meredith ivan@ivan.net.nz wrote:
2009/11/17 Adrian Cole adrian@jclouds.org:
good idea.. One thought: as opposed to supporting less than greater than, we could say we only support equals and at least.
That limits the association to 2 types, which we could (in a hackish way) encode using the two common request parameter types:
query is for squishy matrix is for must be
ex. ;arch=x86?mem=2?core=2
arch must be x86, but I can use anything with at least 2g memory and 2 cores
pros are that we do not need to invent something we'd need to encode, and don't need to parse parameter names.
cons is that the thing is a little weird
wdyt?
I personally think that just using matrix params for this is best. I have no real reason, i just see it as less complicated.
personally i see...
no arch = any ;arch=x86 ;arch=x86|x64
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
I'm following this discussion with interest and I'm wondering what the goal of deltacloud is with respect to supporting every cloud model out there. The path that deltacloud is embarking on judging by the posts in this thread is to support the union of all features of all clouds. The current thread is about changing the machine characteristics of a server. I assume next is changing the characteristics while it's running. If I come along with a cloud that allows the user to change the color of the cooling fan LEDs can I get that added to the API as well? :-) What I'm trying to get at is that the number of dimensions along which IT has tweaked datacenter configurations is virtually infinite. Is the goal of deltacloud to express the superset of all the options out there? If not, what are the guiding principles?
The reasons for which I think it's important to keep the number of choices at bay are: - it quickly becomes a ton of work to implement any system that supports deltacloud: lots of UI to build, lots of rules to follow - the user is faced with a million choices, and we can easily end up in a situation where the majority of choices or combinations are invalid for any given cloud - doing anything in a portable manner becomes more difficult because the "conversion matrix" just explodes
In the end arguing over "I'd like 5GB instead of 4 and 3 cores instead of 4" is missing the forest for the trees. You win in the cloud because boxes are cheap, plentiful, convenient, on demand, and you can make them do what you need to quickly and in a scalable way. Not because you got knobs to tweak the last 20% of performance out of your favorite box. At least that's my experience with real customers spending >$10k/mo on EC2.
Sorry if this sounds like a rant, it's not intended to be. This is a tricky problem and I wanted to raise the question. Thanks much!
Thorsten - CTO RightScale
Hi, Thorsten.
Good point. I'm not quite sure what our guiding principles are, yet, either ;)
What would you consider choices kept at bay? (cores? memory?)
Personally, I'm a fan of two views: consumer cloud (think plain ec2) and enterprise cloud (think vcloud), where the former will have very few choices, and stay simple as possible, while the latter acknowledges the very real need for awareness of class of service and the like.
What do you think?
Sorry, if I'm too dense to scrape that from your input.
Cheers, -Adrian
On Mon, Nov 16, 2009 at 6:13 PM, Thorsten von Eicken tve@rightscale.com wrote:
I'm following this discussion with interest and I'm wondering what the goal of deltacloud is with respect to supporting every cloud model out there. The path that deltacloud is embarking on judging by the posts in this thread is to support the union of all features of all clouds. The current thread is about changing the machine characteristics of a server. I assume next is changing the characteristics while it's running. If I come along with a cloud that allows the user to change the color of the cooling fan LEDs can I get that added to the API as well? :-) What I'm trying to get at is that the number of dimensions along which IT has tweaked datacenter configurations is virtually infinite. Is the goal of deltacloud to express the superset of all the options out there? If not, what are the guiding principles?
The reasons for which I think it's important to keep the number of choices at bay are: - it quickly becomes a ton of work to implement any system that supports deltacloud: lots of UI to build, lots of rules to follow - the user is faced with a million choices, and we can easily end up in a situation where the majority of choices or combinations are invalid for any given cloud - doing anything in a portable manner becomes more difficult because the "conversion matrix" just explodes
In the end arguing over "I'd like 5GB instead of 4 and 3 cores instead of 4" is missing the forest for the trees. You win in the cloud because boxes are cheap, plentiful, convenient, on demand, and you can make them do what you need to quickly and in a scalable way. Not because you got knobs to tweak the last 20% of performance out of your favorite box. At least that's my experience with real customers spending >$10k/mo on EC2.
Sorry if this sounds like a rant, it's not intended to be. This is a tricky problem and I wanted to raise the question. Thanks much!
Thorsten - CTO RightScale
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
== Nutshell
I'd like to see a deltacloud API that accepts there is a lot of variety out there in the virtual machine hosting environments.
I'd like to see an API permitting a provider to express as much of their functionality and features as possible.
Having a rich, expressive API implicitly means that we (or anyone) can create simpler, easier-to-use, APIs based off the richer API. Should we need them.
== Example attributes
VMs managed by the deltacloud API can have a lot of different attributes.
For example: VMs at RimuHosting have attributes like memory, disk space, data center location, network provider, vlans, data transfer allowances, number of IPs, distro/image name, kernel (version, 32/64 bittedness), number of backups history (0, 1 or 2). They run on host servers that have various types (e.g. low contention with say a VPS per core). The host servers have attributes, like number of cores; cpu type; total, free and available memory and disk space.
Some of these attributes users really actually care about. Other's they are happy to accept the default. The attributes people care about varies from person to person (e.g. for some people it is disk size, others memory, others location).
== APIs modeling reality
I think the deltacloud API should be a good API. A good API will model reality as close as we can get it.
== API complexity vs. UI complexity
I think the UI tools should be appropriate to the users. Some users will want nice simple UIs. Others will want to fiddle with the knobs.
With an API that models reality well one should be able to create simple _or_ a complex UI. Only the other hand an overly simple API will prohibit a fully expressive UI.
With a rich API then others can create simpler APIs using the richer API as a back end. And then people can choose to match the right API for the right UI.
== +1 for deltacloud being *the* standard fully featured and expressive API
At some point someone needs to create a rich, fully featured API that is the gold standard for the industry. It would be great if deltacloud were that API.
== Graceful degradation via capabilities interface
Permit the deltacloud drivers to express their capabilities. Write deltacloud so it is easy to add more capability attributes without breaking drivers.
e.g. I'd suggest matrix params for expressing min/max and preferred attributes.
e.g. min_mem_mb=256;preferred_mem_mb=512;max_mem_mb=1024
Then the providers that have fixed size VMs would provide a 'size' that fits in that range. For providers that can handle the sliding ranges, then they'd return something closer to the preferred value.
If a driver sees a min_* attribute that it does not know about or knows it does not support, then it returns 0 plans/sizes. e.g. if RimuHosting got a min_has_led_color=Y then we'd return 0 matching plans. (But quickly figure out how to get more servers with LEDs of the popular colors).
== Fixed sizes vs. variable sizes
At RimuHosting we have pricing plans. Which are standard-sized VMs. But that is really just a marketing here-is-a-url-starting-point-to-order something. Really we'd be happy providing a customer with any combination of disk, memory, etc, as would nicely fit on one of our hosts.
Other companies (EC2, slicehost, ... ?) focus more on the fixed sizes.
To get the most end-users, have lots of 3rd party tool support and encourage having the widest selection of providers deltacloud should cope with a variety of provisioning types.
== Document the reasonable-attribute-set starting point
We should 'start' with a good set of reasonable attributes that would describe the things most customers care about. I'd have some more thoughts on what these should be.
Thorsten von Eicken wrote:
there. The path that deltacloud is embarking on judging by the posts in this thread is to support the union of all features of all clouds. The
I think a good expressive API should be able to model a reasonable range of providers with varying capabilities. And not break if not all providers fail to have all the capabilities. This may require an interface to expose a driver's supported operations? e.g. whether VPS resizes are supported; vps moves (from host-to-host or datacenter-to-datacenter); what billing interfaces are provides; etc.
current thread is about changing the machine characteristics of a server. I assume next is changing the characteristics while it's running.
A lot (30%?) of our customers resize their instance every several months (vs. tearing it down and starting afresh). So that would be something that they would find useful to do via deltacloud, too.
:-) What I'm trying to get at is that the number of dimensions along which IT has tweaked datacenter configurations is virtually infinite. Is the goal of deltacloud to express the superset of all the options out there? If not, what are the guiding principles?
I like APIs that model reality as simply-and-closely as possible (yes 'simply' and 'closely' pull and tug at each other).
The reasons for which I think it's important to keep the number of choices at bay are:
- it quickly becomes a ton of work to implement any system that
supports deltacloud: lots of UI to build, lots of rules to follow
If a driver can express its capabilities clearly this may help the UI creation.
- the user is faced with a million choices, and we can easily end up in
a situation where the majority of choices or combinations are invalid for any given cloud
It is possible to create a simple UI if the API models the real world well enough.
- doing anything in a portable manner becomes more difficult because
the "conversion matrix" just explodes
People would be able to write libraries based off of a 'rich' fully-featured deltacloud API that expose a simpler interface. If necessary. i.e. creating an expressive API permits the creation of less expressive, simpler APIs.
This is appealing to me as a implementor of VM API driver, since I can write our fully featured deltacloud driver. And then know that the 3rd party, dumbed down drivers will 'just work' without us having to contribute to yet-another-driver-project.
Thorsten - CTO RightScale
Regards, Peter http://rimuhosting.com
Funny, I was thinking the same thing! We must be on the same wavelength, Bob. One thing I like about the profile, where I envisioned it, is that it makes the whole thing very flexible for the requestor. Ex, I need x86 with at least 4gb and don't care about the rest. With a profile system, this is easy to satisfy across providers.
Nice one. Adrian jclouds
On Nov 16, 2009 6:12 AM, "Bryan Kearney" bkearney@redhat.com wrote:
On 11/16/2009 09:06 AM, Bob McWhirter wrote: > Howdy folks-- > > Been thinking about the flavor/hard... Would they get the attributes similar to what you have below?
These would specify the different profiles available, in terms of min/ >
max capabilities for eac... 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...
Bob McWhirter wrote:
Howdy folks--
Been thinking about the flavor/hardware problem some, and he's my initial thoughts:
We should remove "flavors" as they exist now, and replace them with "hardware profiles" (or some other name).
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
So in this case the profile doesn't specify the exact HW config. This still leaves the question of whether the exact memory, etc. params are determined by the user creating the instance or by the cloud by some default/automatic process by the driver and/or cloud provider. In addition we will need to add fields to the Instance model to track what the _actual_ memory, disk, and cpu values are for an instance, whether user-selected or chosen by the cloud.
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.
Yes, so to support the parameterization we'll also need memory, disk, and cpu added to the instance model so we will know what portion of the range was selected by the user or cloud.
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.
Thoughts?
-Bob _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
So in this case the profile doesn't specify the exact HW config. This still leaves the question of whether the exact memory, etc. params are determined by the user creating the instance or by the cloud by some default/automatic process by the driver and/or cloud provider. In addition we will need to add fields to the Instance model to track what the _actual_ memory, disk, and cpu values are for an instance, whether user-selected or chosen by the cloud.
I think a profile should specify 'default' values for everything, so that unparameterized launching is still meaningful. Or if no defaults are specified, the minimum is used.
Yes, so to support the parameterization we'll also need memory, disk, and cpu added to the instance model so we will know what portion of the range was selected by the user or cloud.
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.
Yah, and I think these attributes get recorded into the instance so they match reality, regardless of if they come from defaults, or are explicitly specified.
A back-ref to the spawning profile also would be useful, in the case of mutability, so you can examine allowable ranges later.
-Bob
deltacloud-devel@lists.fedorahosted.org
-
Adrian Cole -
Adrian Cole -
Bob McWhirter -
Bryan Kearney -
Ivan Meredith -
Peter Bryant -
Scott Seago -
Thomas von Steiger -
Thorsten von Eicken