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