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
>

Reply via email to