You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@libcloud.apache.org by Tom Davis <to...@recursivedream.com> on 2012/09/30 14:35:20 UTC
Re: [dev] Cleaning up the mess called Rackspace Compute drivers
(moving all of the functionality from 6 classes into two classes and making
it more user friendly)
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" <to...@apache.org> 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
>
Re: [dev] Cleaning up the mess called Rackspace Compute drivers
(moving all of the functionality from 6 classes into two classes and making
it more user friendly)
Posted by Tomaž Muraus <to...@apache.org>.
Current beta druver actually uses a different entry from the service
catalog.
I do agree that beta is not a location so we should probably have a
separate driver for it. This would put us to a total of 3 drivers /
constants for Rackspace.
On Sun, Sep 30, 2012 at 5:35 AM, Tom Davis <to...@recursivedream.com> wrote:
> 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" <to...@apache.org> 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
> >
>
Re: [dev] Cleaning up the mess called Rackspace Compute drivers
(moving all of the functionality from 6 classes into two classes and making
it more user friendly)
Posted by Tomaž Muraus <to...@apache.org>.
Current beta druver actually uses a different entry from the service
catalog.
I do agree that beta is not a location so we should probably have a
separate driver for it. This would put us to a total of 3 drivers /
constants for Rackspace.
On Sun, Sep 30, 2012 at 5:35 AM, Tom Davis <to...@recursivedream.com> wrote:
> 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" <to...@apache.org> 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
> >
>