Current beta druver actually uses a different entry from the service catalog.
I do agree that beta is not a location so we should probably have a separate driver for it. This would put us to a total of 3 drivers / constants for Rackspace. On Sun, Sep 30, 2012 at 5:35 AM, Tom Davis <[email protected]> wrote: > It certainly sounds reasonable to me. I don't fully understand the > "locations" though—"Beta" isn't a place and it seems like all the locations > for that provider class use the same Beta stack anyway. > On Sep 30, 2012 3:29 AM, "Tomaž Muraus" <[email protected]> wrote: > > > All, > > > > In the past couple of months Rackspace drivers kinda got out of control. > We > > currently have 6 different constants and compute drivers for Rackspace: > > > > - RACKSPACE (first-gen cloud servers) > > - RACKSPACE_UK (first-gen cloud servers in the UK) > > - Provider.RACKSPACE_NOVA_BETA (next-gen openstack based cloud servers) > > - Provider.RACKSPACE_NOVA_DFW (next-gen openstack based cloud servers DFW > > datacenter) > > - Provider.RACKSPACE_NOVA_ORD (next-gen openstack based cloud servers ORD > > datacenter) > > - Provider.RACKSPACE_NOVA_LON (next-gen openstack based cloud servers in > > the UK) > > > > All of the classes work, but the problem is that it is very confusing and > > non user-friendly. > > > > I have finally dedicated some time this weekend for fixing this mess. I > > plan to turn those 6 classes and constants into 2 classes and constants: > > > > - Provider.RACKSPACE (RackspaceNodeDriver class) > > > > Function signature: (key, secret, region='us|uk|beta', 'datacenter': > > 'dfw|ord') > > > > Next-gen cloud servers are the future for Rackspace and that is why this > > constant would now point to the next-gen driver by default. > > > > - RACKSPACE_FIRST_GEN (RackspaceFirstGenNodeDriver class) > > > > Function signature: (key, secret, region='us|uk') > > > > Old driver which has previously been referenced using RACKSPACE constant > is > > now deprecated and can be referenced using RACKSPACE_FIRST_GEN provider > > constant. > > > > Keep in mind that this is also a first step in making entire Libcloud > > better and more easy to use with providers which have multiple locations > > and availability zones (looking at you AWS driver). > > > > Over the next few months I plan to iterate on it, standardize on good > > approach and repeat this pattern in other drivers. > > > > To keep the code clean and reduce technical debt I think that this time > we > > shouldn't keep a bunch of old classes lying around for backward > > compatibility. We should remove them, bump the version to indicate a > > breaking change and document changes in the "Upgrade Notes" section on > the > > website. > > > > Feedback? Questions? > > > > Thanks, > > Tomaz > > >
