Latest version of the Rackspace drivers in trunk now looks like this: There are two providers constants:
- Provider.RACKSPACE - new OpenStack based cloud servers - Provider.RACKSPACE_FIRST_GEN - old first-gen cloud servers (previously Provider.RACKSPACE) When you instantiate a first-gen driver you can also pass 'region' argument to the constructor which defaults to 'us'. Other possible option is 'uk'. When you instantiate a next-gen driver you can also pass 'datacenter' argument to the constructor which defaults to 'dfw'. Other possible options are 'ord' and 'lon'. First-gen driver takes a 'region' instead of 'datacenter' argument because the datacenter where the server is created is chosen automatically and a user can't control it. I'm pretty happy with this approach. If there aren't any objections or concerns I will start a voting thread for a new release which includes those changes in the next couple of weeks. On Mon, Oct 1, 2012 at 12:52 PM, Tomaž Muraus <to...@apache.org> wrote: > 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 >> >> >> >