You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Tomaž Muraus <to...@apache.org> on 2012/09/30 09:29:04 UTC
[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)
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
[dev] Re: 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>.
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 <da...@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
>>
>>
>>
>
Re: 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>.
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 <da...@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
>>
>>
>>
>
Re: 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>.
Replies are in-line.
On Mon, Oct 1, 2012 at 4:21 AM, Dave King <da...@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
>
>
>
[dev] Re: 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>.
Replies are in-line.
On Mon, Oct 1, 2012 at 4:21 AM, Dave King <da...@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
>
>
>
[dev] RE: 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 Dave King <da...@mailtrust.com>.
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.
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.)
Regards,
Dave
--
Rackspace Cloud
Software Developer
Internal#: 505 2212
External#: (540) 443-2212
Cell #: (814) 404-0208
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
> >
>
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 Tom Davis <to...@recursivedream.com>.
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: 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 Dave King <da...@mailtrust.com>.
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.
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.)
Regards,
Dave
--
Rackspace Cloud
Software Developer
Internal#: 505 2212
External#: (540) 443-2212
Cell #: (814) 404-0208
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 Tom Davis <to...@recursivedream.com>.
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
>