Replies are in-line. On Mon, Oct 1, 2012 at 4:21 AM, Dave King <dave.k...@mailtrust.com> wrote:
> On Sunday, September 30, 2012 3:29am, "Tomaž Muraus" <to...@apache.org> > said: > > > 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? > > Big fan of the cleanup and in getting regions no longer hardcoded in the > class definition. > > Is there a reason to keep around the beta driver? I believe that once > upon a time the beta driver existed because NextGen Cloud Servers was not > available through production Rackspace auth. > Nope, I actually removed the beta driver during the cleanup yesterday. > However right now I believe the Beta driver points to a staging auth > system -- I don't know who consumes this other than Rackspace employees. > > If we remove the beta driver could we remove the 'region' concept? The > only inelegant thing there is that the LON datacenter doesn't respond to US > auth and so choose LON would have to understand there is a shift in auth > provider. (However as Rackspace customers are either US/UK currently I > guess that matches their customer experience.) > I just talked with Paul offline and I agree with you and think we should go with a single argument called datacenter which can be one of the following: - dfw - ord - lon This puts some more work on us (figuring out which auth endpoint to us), but it makes it even easier for the user. > Regards, > > Dave > -- > Rackspace Cloud > Software Developer > Internal#: 505 2212 > External#: (540) 443-2212 > Cell #: (814) 404-0208 > > >