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

Reply via email to