Hi, Sorry for a late response.
I think the factory approach we use in the OpenStack driver* is reasonable and should be reused with other drivers which support multiple API versions. * Base driver class with a common functionality and a separate class for every API version which inherits from the base class. Constructor in the base class should also take "api_version" argument which tells it which class to actually instantiate. On Sat, Mar 24, 2012 at 1:35 AM, Sengor <[email protected]> wrote: > Hi, > > The current vCloud compute driver is specific to preliminary v0.8 of > the API spec and largely compatible with Terremark & Hosting.com > service providers. I'm looking at extending the existing functionality > to suit v1.5 of the API spec in a service provider agnostic manner. > ie. This driver would be compatible with generic v1.5 deployments of > vCloud running within a lab (or at least this is how I hope it'll turn > out). > > I'd like to know whether anyone else is already working/thinking about > something similar (VMware don't seem to be concerned about Python > SDKs/libs at present). Also would be good to know whether others would > make use of such functionality. > > How would you recommend to best structure a provider independent > vCloud v1.5 compatible compute driver? > > I can see two options at this stage: > 1) Overhaul the current vCloud driver to support both v0.8 and v1.5 > independently (skipping intermediate versions eg. v0.9, v1.0) - by > introducing new classes: VCloud_1_5_NodeDriver(), > VCloud_1_5_Connection(), VCloud_1_5_InstantiateVAppXML() > 2) Introduce a separate driver for API v1.5 under > compute/drivers/vcloud15.py > > Perhaps this brings up a more general question of how to handle API > versions and service provider specific compatibility across different > drivers... Current pattern in OpenStack driver seems to be: handle > everything within the same driver via differing classes (#1 from > above). > > Note this is just a though experiment at this stage. Thank you. > > / Disclaimer: I'm not affiliated with VMware / > > -- > sengork >
