The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific.
We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc).
I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will.
Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.)
Any commets/ideas?
Regards, Ivan
My thoughts: yes the create_instances is pretty minimal, but I am not sure that it is right just yet to allow "undefined" provider specific data - once we open that gate, millions of things will gallop through it in future ;)
I think there is still a LOT more in common between providers than there is different, from most users points of view, so we should spend more time understanding what that is and trying to describe that into the API first, and once that is exhausted and there are still things that are really needed that don't fit, then we open that gate.
The state of clouds are a bit like pre posix days, or early "app server" days - every vendor has something "special" that only they do (or it seems that way), and it simply must be in the standard... but over time the differences flatten out to what people really need.
At least that is my thoughts and experience so far.
On Wed, Oct 28, 2009 at 8:29 AM, Ivan Meredith ivan@ivan.net.nz wrote:
The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific. We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc). I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will. Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.) Any commets/ideas? Regards, Ivan
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
-----Original Message----- From: deltacloud-devel-bounces@lists.fedorahosted.org
[mailto:deltacloud-
devel-bounces@lists.fedorahosted.org] On Behalf Of Michael Neale Sent: Tuesday, October 27, 2009 23:48 PM To: Ivan Meredith Cc: deltacloud-devel@lists.fedorahosted.org Subject: Re: [deltacloud-devel] Options for create instance
My thoughts: yes the create_instances is pretty minimal, but I am not sure that it is right just yet to allow "undefined" provider specific data - once we open that gate, millions of things will gallop through it in future ;)
I think there is still a LOT more in common between providers than there is different, from most users points of view, so we should spend more time understanding what that is and trying to describe that into the API first, and once that is exhausted and there are still things that are really needed that don't fit, then we open that gate.
The state of clouds are a bit like pre posix days, or early "app server" days - every vendor has something "special" that only they do (or it seems that way), and it simply must be in the standard... but over time the differences flatten out to what people really need.
[IH] I agree, at least to start with, a good approach seems the one the Libvirt project took of trying to abstract and generalize, so api calls can be converted with the same meaning to as many clouds as possible.
Billing for public clouds, or charge-back for internal clouds are both important and useful concepts.
Like other parameters, I'm happy to add this, as long as we have a "reasonable default" for folks who don't specify it.
In EC2's case, there's no flexibility in billing targets when launching, so if specified, it should always have the value of 'default', let's say.
So, I'd prefer to bake "billing-target" as an opaque string, with a default value of "default", right into the API, and not hide it in an opaque opts hash.
Drivers that don't support it, don't have to care.
We may certainly need a provider-specific opts hash at some point, but I think right now we're still discovering core API bits that should be well-defined across drivers.
-Bob
On Oct 27, 2009, at 5:48 PM, Michael Neale wrote:
My thoughts: yes the create_instances is pretty minimal, but I am not sure that it is right just yet to allow "undefined" provider specific data - once we open that gate, millions of things will gallop through it in future ;)
I think there is still a LOT more in common between providers than there is different, from most users points of view, so we should spend more time understanding what that is and trying to describe that into the API first, and once that is exhausted and there are still things that are really needed that don't fit, then we open that gate.
The state of clouds are a bit like pre posix days, or early "app server" days - every vendor has something "special" that only they do (or it seems that way), and it simply must be in the standard... but over time the differences flatten out to what people really need.
At least that is my thoughts and experience so far.
On Wed, Oct 28, 2009 at 8:29 AM, Ivan Meredith ivan@ivan.net.nz wrote:
The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific. We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc). I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will. Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.) Any commets/ideas? Regards, Ivan
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Wed, Oct 28, 2009 at 10:29:32AM +1300, Ivan Meredith wrote:
The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific.
We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc).
I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will.
Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.)
Any commets/ideas?
Well...
One of the ways we have made libvirt (http://libvirt.org) successful is by refusing to do exactly this -- i.e. instead of allowing arbitrary options to pass through to a driver, do the hard thinking now about what specific options we want to support vs. what ones we don't (and define the API in such a way that it is easy to extend as necessary). This is what will ultimately make Deltacloud into a viable API, rather than just a thin shell around a bunch of provider-specific code.
So, for example, if billing method is an important parameter, then we should figure out how to model that in the "create instance" API, develop a schema for it, and freeze it.
If we go the "arbitrary options can pass through" route, ultimately we're not providing as much value as we could to consumers of the API (because they now have to have cloud-provider-specific code in their applications). Instead we want Deltacloud consumers to be able to write for the Deltacloud API exclusively, without having to consider which driver they might be talking to.
Take care, --Hugh
Well said hugh - yes that was my feeling exactly.
On the topic of billing, I heard rumours that at one point your amazon EC2 account could let you order ANYthing (there was a case of something buying themself an expesive present on their companies dime !) - but I digress....
Can someone clarify the relationship (if any) between the python libcloud and deltacloud?
On Wed, Oct 28, 2009 at 8:48 AM, Hugh O. Brock hbrock@redhat.com wrote:
On Wed, Oct 28, 2009 at 10:29:32AM +1300, Ivan Meredith wrote:
The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific.
We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc).
I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will.
Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.)
Any commets/ideas?
Well...
One of the ways we have made libvirt (http://libvirt.org) successful is by refusing to do exactly this -- i.e. instead of allowing arbitrary options to pass through to a driver, do the hard thinking now about what specific options we want to support vs. what ones we don't (and define the API in such a way that it is easy to extend as necessary). This is what will ultimately make Deltacloud into a viable API, rather than just a thin shell around a bunch of provider-specific code.
So, for example, if billing method is an important parameter, then we should figure out how to model that in the "create instance" API, develop a schema for it, and freeze it.
If we go the "arbitrary options can pass through" route, ultimately we're not providing as much value as we could to consumers of the API (because they now have to have cloud-provider-specific code in their applications). Instead we want Deltacloud consumers to be able to write for the Deltacloud API exclusively, without having to consider which driver they might be talking to.
Take care, --Hugh _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Oct 28, 2009, at 6:51 PM, Michael Neale wrote:
Well said hugh - yes that was my feeling exactly.
On the topic of billing, I heard rumours that at one point your amazon EC2 account could let you order ANYthing (there was a case of something buying themself an expesive present on their companies dime !) - but I digress....
Yes yes, it's your amazon account, with a credit-card stored on-file, which I can also use for one-click shopping of sketchy and subversive reading materials.
Amazon's whole permission/credential/payment scheme is truly weird and non-production-friendly. Shared creds? Really? At least the SOAP API is secured with X.509. <sarcasm/>
-Bob
Can someone clarify the relationship (if any) between the python libcloud and deltacloud?
On Wed, Oct 28, 2009 at 8:48 AM, Hugh O. Brock hbrock@redhat.com wrote:
On Wed, Oct 28, 2009 at 10:29:32AM +1300, Ivan Meredith wrote:
The REST API for creating instances is fairly minimal. It would be good if we could pass some custom options to it. These would be optional of course, and provider specific.
We allow customers to clone another instance if they want to, or choose a billing method (some like to have multiple CC's or some servers on Wire Transfer etc).
I propose something like, any options that don't match the 4 specified in the API, are bundled up into an opts hash, and given to the providers driver. Then they could use them at will.
Possibly there might be a way for something like the portal to be able to specify some dynamic options by returning a list of options from the driver (or provider api). (Actaully I'm still trying to get the portal working with the mock driver, so I assume it can create instances.)
Any commets/ideas?
Well...
One of the ways we have made libvirt (http://libvirt.org) successful is by refusing to do exactly this -- i.e. instead of allowing arbitrary options to pass through to a driver, do the hard thinking now about what specific options we want to support vs. what ones we don't (and define the API in such a way that it is easy to extend as necessary). This is what will ultimately make Deltacloud into a viable API, rather than just a thin shell around a bunch of provider- specific code.
So, for example, if billing method is an important parameter, then we should figure out how to model that in the "create instance" API, develop a schema for it, and freeze it.
If we go the "arbitrary options can pass through" route, ultimately we're not providing as much value as we could to consumers of the API (because they now have to have cloud-provider-specific code in their applications). Instead we want Deltacloud consumers to be able to write for the Deltacloud API exclusively, without having to consider which driver they might be talking to.
Take care, --Hugh _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel@lists.fedorahosted.org
-
Bob McWhirter -
Hugh O. Brock -
iheim＠redhat.com -
Ivan Meredith -
Michael Neale