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