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
>
>
>

Reply via email to