You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by anthony shaw <an...@gmail.com> on 2015/10/23 01:37:08 UTC
[dev] suggestions for 0.20.0
I had some suggestions for the next version,
1) Azure Driver:
* Only supports the 'old' way of authenticating, continue this method
* Offer the new Azure AD/OAuth method as a secondary option for
instantiating a driver -
https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
This is Microsoft's recommended approach and it's probably a matter of time
until they stop supporting certificates (according to an 'insider').
2) A Backup Driver type:
I'm looking at adding support for the DD Cloud Backup service and it
doesn't really fall under the compute functionality. There are a few other
providers offering very similar functionality on the market
Azure
Rackspace
Dimension Data
https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide/
Azure
https://azure.microsoft.com/en-us/services/backup/
This would be very similar to the DNS driver type.
3) Removing the opsource driver, this is superseded by the Dimension Data
driver and has been for a while now.
Ant
RE: [dev] Re: suggestions for 0.20.0
Posted by anthony shaw <an...@gmail.com>.
Thanks Richard for the insight,
If we can support both Oauth and x509, keeping constructor backward compat with the last version. But not move to ARM because I agree with you it's not appropriate for libcloud. My understanding was that you should use oauth with the API in place of certs simply as a different authentication mechanism.
I'll submit a PoC PR this week for review
Sent from Outlook
On Sat, Oct 24, 2015 at 5:11 AM -0700, "Richard Conway" <ri...@elastacloud.com> wrote:
Couple of points (since I contributed to the original Azure compute driver)
1. The majority of users and enterprises using Azure are still using what Microsoft term "Classic" mode. This isn’t going away anytime soon although it is compounded by the fact that ARM and Classic are mutually exclusive such that you can't use "v1" with "v2" resources.
2. ARM itself is not a great fit for libcloud so it needs to be carefully thought about. It ties vnets, storage and compute together and makes certain things bound to one another (through ARM templates). In effect it does much of the job that you would be doing programmatically in libcloud.
That said it's probably worthwhile ADDING (not replacing) oauth through Microsoft and work and school accounts. Many people are still using .publishsettings files to generate X509 so a replacement would cause issues with many users current workflow. Microsoft, themselves, still support both through Powershell CmdLets with a Switch-Mode CmdLet (although this may be deprecated soon in favor of something simpler).
Cheers,
Richard
-----Original Message-----
From: anthony shaw [mailto:anthony.p.shaw@gmail.com]
Sent: Friday, October 23, 2015 11:13 PM
To: dev@libcloud.apache.org; dev
Subject: Re: [dev] Re: suggestions for 0.20.0
Wrt item 1, we wouldn't need to add it as a dependency, you can just use the requests library to get the token for oauth. That's all they are doing. And their SDK looks pretty incomplete so it wouldn't be a good dependency. I'm happy to do that task, I've got lots of accounts on azure to test on and plenty of VMs. It's probably time I contributed to another driver!
Wrt the backup, I'll send a comparison of the features in azure, Rackspace and dimension data to help with a base class. I'd got that somewhere anyway from prior research building our own service. I would imagine some of the other providers have also. Ant
Sent from Outlook
On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" wrote:
All good stuff.
1. As far as depending on the 3rd party libraries / packages goes - in the past we avoided that because it's harder to test it and make sure it works under all the Python versions we support.
2. Introducing a new API usually requires more work which includes a proposal to the mailing list and a prototype / initial implementation with at least 2 drivers (3 are better).
The reason for at least 2 drivers is to make sure that the base API and implementation is indeed generic (as much as possible) and not biased towards a single provider...
3. Yeah, some cleaning is in order. Would be good to check which providers are now dead and remove those drivers (HP just announced sun set of their public cloud offering so in a couple of months we can get rid of that driver as well).
On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
wrote:
> WRT item 1)
>
> Microsoft have already implemented this approach in the
> azure-python-sdk pypi.
>
>
> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagem
> entauthentication.html
>
>
> Ant
>
> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
> wrote:
>
> > I had some suggestions for the next version,
> >
> >
> > 1) Azure Driver:
> > * Only supports the 'old' way of authenticating, continue this
> > method
> > * Offer the new Azure AD/OAuth method as a secondary option for
> > instantiating a driver -
> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> > This is Microsoft's recommended approach and it's probably a matter
> > of time until they stop supporting certificates (according to an 'insider').
> >
> > 2) A Backup Driver type:
> >
> > I'm looking at adding support for the DD Cloud Backup service and it
> > doesn't really fall under the compute functionality. There are a few
> other
> > providers offering very similar functionality on the market
> >
> > Azure
> > Rackspace
> > Dimension Data
> >
> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide
> > /
> > Azure
> > https://azure.microsoft.com/en-us/services/backup/
> >
> > This would be very similar to the DNS driver type.
> >
> > 3) Removing the opsource driver, this is superseded by the Dimension
> > Data driver and has been for a while now.
> >
> > Ant
> >
>
Re: [dev] Re: suggestions for 0.20.0
Posted by anthony shaw <an...@gmail.com>.
@kami and the Ninefold driver, they just announced shutting down their
cloud https://ninefold.com/news/
On Tue, Oct 27, 2015 at 3:18 AM, Richard Conway <ri...@elastacloud.com>
wrote:
> Hi Peter,
>
> I've been up to my eyes at work this month but took a look at the code a
> while ago and will fork this weekend. Keen to contribute to tests. Have a
> wide breadth of experience with ARM so happy to build in some standard unit
> test scenarios and a couple of integration tests to model the github
> quickstarts.
>
> All the best,
>
> Richard
>
> -----Original Message-----
> From: Peter Amstutz [mailto:peter.amstutz@curoverse.com]
> Sent: Monday, October 26, 2015 1:59 PM
> To: dev@libcloud.apache.org
> Subject: Re: [dev] Re: suggestions for 0.20.0
>
> I have written a fairly complete Azure ARM compute driver for libcloud,
> which is available here (including the ability to do OAuth2 authentication
> to get an API token).
>
> https://github.com/curoverse/libcloud
>
> I would like to upstream it, but haven't had the resources to write tests,
> so I've just been sitting on it for the last couple of months (we are using
> it internally). Perhaps I should go ahead and make a pull request, to get
> code review feedback?
>
> By the way, ARM templates are just a thin layer on top of the REST API.
> Templates are useful for scripted deployment, but the underlying ARM JSON
> REST API is a mostly straightforward match for libcloud (with some gotchas
> that I can go into if anyone is interested.)
>
> Thanks,
> Peter
>
> On Sat, Oct 24, 2015 at 8:10 AM, Richard Conway <ri...@elastacloud.com>
> wrote:
> > Couple of points (since I contributed to the original Azure compute
> > driver)
> >
> > 1. The majority of users and enterprises using Azure are still using
> what Microsoft term "Classic" mode. This isn’t going away anytime soon
> although it is compounded by the fact that ARM and Classic are mutually
> exclusive such that you can't use "v1" with "v2" resources.
> > 2. ARM itself is not a great fit for libcloud so it needs to be
> carefully thought about. It ties vnets, storage and compute together and
> makes certain things bound to one another (through ARM templates). In
> effect it does much of the job that you would be doing programmatically in
> libcloud.
> >
> > That said it's probably worthwhile ADDING (not replacing) oauth through
> Microsoft and work and school accounts. Many people are still using
> .publishsettings files to generate X509 so a replacement would cause issues
> with many users current workflow. Microsoft, themselves, still support both
> through Powershell CmdLets with a Switch-Mode CmdLet (although this may be
> deprecated soon in favor of something simpler).
> >
> > Cheers,
> >
> > Richard
> >
> > -----Original Message-----
> > From: anthony shaw [mailto:anthony.p.shaw@gmail.com]
> > Sent: Friday, October 23, 2015 11:13 PM
> > To: dev@libcloud.apache.org; dev <de...@libcloud.apache.org>
> > Subject: Re: [dev] Re: suggestions for 0.20.0
> >
> > Wrt item 1, we wouldn't need to add it as a dependency, you can just use
> the requests library to get the token for oauth. That's all they are doing.
> And their SDK looks pretty incomplete so it wouldn't be a good dependency.
> I'm happy to do that task, I've got lots of accounts on azure to test on
> and plenty of VMs. It's probably time I contributed to another driver!
> > Wrt the backup, I'll send a comparison of the features in azure,
> > Rackspace and dimension data to help with a base class. I'd got that
> > somewhere anyway from prior research building our own service. I would
> > imagine some of the other providers have also. Ant
> >
> > Sent from Outlook
> >
> >
> >
> >
> > On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" <to...@apache.org>
> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > All good stuff.
> >
> > 1. As far as depending on the 3rd party libraries / packages goes - in
> the past we avoided that because it's harder to test it and make sure it
> works under all the Python versions we support.
> >
> > 2. Introducing a new API usually requires more work which includes a
> proposal to the mailing list and a prototype / initial implementation with
> at least 2 drivers (3 are better).
> >
> > The reason for at least 2 drivers is to make sure that the base API and
> implementation is indeed generic (as much as possible) and not biased
> towards a single provider...
> >
> > 3. Yeah, some cleaning is in order. Would be good to check which
> providers are now dead and remove those drivers (HP just announced sun set
> of their public cloud offering so in a couple of months we can get rid of
> that driver as well).
> >
> > On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
> > wrote:
> >
> >> WRT item 1)
> >>
> >> Microsoft have already implemented this approach in the
> >> azure-python-sdk pypi.
> >>
> >>
> >> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanage
> >> m
> >> entauthentication.html
> >>
> >>
> >> Ant
> >>
> >> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
> >> wrote:
> >>
> >> > I had some suggestions for the next version,
> >> >
> >> >
> >> > 1) Azure Driver:
> >> > * Only supports the 'old' way of authenticating, continue this
> >> > method
> >> > * Offer the new Azure AD/OAuth method as a secondary option for
> >> > instantiating a driver -
> >> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> >> > This is Microsoft's recommended approach and it's probably a matter
> >> > of time until they stop supporting certificates (according to an
> 'insider').
> >> >
> >> > 2) A Backup Driver type:
> >> >
> >> > I'm looking at adding support for the DD Cloud Backup service and
> >> > it doesn't really fall under the compute functionality. There are a
> >> > few
> >> other
> >> > providers offering very similar functionality on the market
> >> >
> >> > Azure
> >> > Rackspace
> >> > Dimension Data
> >> >
> >> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guid
> >> > e
> >> > /
> >> > Azure
> >> > https://azure.microsoft.com/en-us/services/backup/
> >> >
> >> > This would be very similar to the DNS driver type.
> >> >
> >> > 3) Removing the opsource driver, this is superseded by the
> >> > Dimension Data driver and has been for a while now.
> >> >
> >> > Ant
> >> >
> >>
>
RE: [dev] Re: suggestions for 0.20.0
Posted by Richard Conway <ri...@elastacloud.com>.
Hi Peter,
I've been up to my eyes at work this month but took a look at the code a while ago and will fork this weekend. Keen to contribute to tests. Have a wide breadth of experience with ARM so happy to build in some standard unit test scenarios and a couple of integration tests to model the github quickstarts.
All the best,
Richard
-----Original Message-----
From: Peter Amstutz [mailto:peter.amstutz@curoverse.com]
Sent: Monday, October 26, 2015 1:59 PM
To: dev@libcloud.apache.org
Subject: Re: [dev] Re: suggestions for 0.20.0
I have written a fairly complete Azure ARM compute driver for libcloud, which is available here (including the ability to do OAuth2 authentication to get an API token).
https://github.com/curoverse/libcloud
I would like to upstream it, but haven't had the resources to write tests, so I've just been sitting on it for the last couple of months (we are using it internally). Perhaps I should go ahead and make a pull request, to get code review feedback?
By the way, ARM templates are just a thin layer on top of the REST API. Templates are useful for scripted deployment, but the underlying ARM JSON REST API is a mostly straightforward match for libcloud (with some gotchas that I can go into if anyone is interested.)
Thanks,
Peter
On Sat, Oct 24, 2015 at 8:10 AM, Richard Conway <ri...@elastacloud.com> wrote:
> Couple of points (since I contributed to the original Azure compute
> driver)
>
> 1. The majority of users and enterprises using Azure are still using what Microsoft term "Classic" mode. This isn’t going away anytime soon although it is compounded by the fact that ARM and Classic are mutually exclusive such that you can't use "v1" with "v2" resources.
> 2. ARM itself is not a great fit for libcloud so it needs to be carefully thought about. It ties vnets, storage and compute together and makes certain things bound to one another (through ARM templates). In effect it does much of the job that you would be doing programmatically in libcloud.
>
> That said it's probably worthwhile ADDING (not replacing) oauth through Microsoft and work and school accounts. Many people are still using .publishsettings files to generate X509 so a replacement would cause issues with many users current workflow. Microsoft, themselves, still support both through Powershell CmdLets with a Switch-Mode CmdLet (although this may be deprecated soon in favor of something simpler).
>
> Cheers,
>
> Richard
>
> -----Original Message-----
> From: anthony shaw [mailto:anthony.p.shaw@gmail.com]
> Sent: Friday, October 23, 2015 11:13 PM
> To: dev@libcloud.apache.org; dev <de...@libcloud.apache.org>
> Subject: Re: [dev] Re: suggestions for 0.20.0
>
> Wrt item 1, we wouldn't need to add it as a dependency, you can just use the requests library to get the token for oauth. That's all they are doing. And their SDK looks pretty incomplete so it wouldn't be a good dependency. I'm happy to do that task, I've got lots of accounts on azure to test on and plenty of VMs. It's probably time I contributed to another driver!
> Wrt the backup, I'll send a comparison of the features in azure,
> Rackspace and dimension data to help with a base class. I'd got that
> somewhere anyway from prior research building our own service. I would
> imagine some of the other providers have also. Ant
>
> Sent from Outlook
>
>
>
>
> On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" <to...@apache.org> wrote:
>
>
>
>
>
>
>
>
>
>
> All good stuff.
>
> 1. As far as depending on the 3rd party libraries / packages goes - in the past we avoided that because it's harder to test it and make sure it works under all the Python versions we support.
>
> 2. Introducing a new API usually requires more work which includes a proposal to the mailing list and a prototype / initial implementation with at least 2 drivers (3 are better).
>
> The reason for at least 2 drivers is to make sure that the base API and implementation is indeed generic (as much as possible) and not biased towards a single provider...
>
> 3. Yeah, some cleaning is in order. Would be good to check which providers are now dead and remove those drivers (HP just announced sun set of their public cloud offering so in a couple of months we can get rid of that driver as well).
>
> On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
> wrote:
>
>> WRT item 1)
>>
>> Microsoft have already implemented this approach in the
>> azure-python-sdk pypi.
>>
>>
>> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanage
>> m
>> entauthentication.html
>>
>>
>> Ant
>>
>> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
>> wrote:
>>
>> > I had some suggestions for the next version,
>> >
>> >
>> > 1) Azure Driver:
>> > * Only supports the 'old' way of authenticating, continue this
>> > method
>> > * Offer the new Azure AD/OAuth method as a secondary option for
>> > instantiating a driver -
>> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
>> > This is Microsoft's recommended approach and it's probably a matter
>> > of time until they stop supporting certificates (according to an 'insider').
>> >
>> > 2) A Backup Driver type:
>> >
>> > I'm looking at adding support for the DD Cloud Backup service and
>> > it doesn't really fall under the compute functionality. There are a
>> > few
>> other
>> > providers offering very similar functionality on the market
>> >
>> > Azure
>> > Rackspace
>> > Dimension Data
>> >
>> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guid
>> > e
>> > /
>> > Azure
>> > https://azure.microsoft.com/en-us/services/backup/
>> >
>> > This would be very similar to the DNS driver type.
>> >
>> > 3) Removing the opsource driver, this is superseded by the
>> > Dimension Data driver and has been for a while now.
>> >
>> > Ant
>> >
>>
Re: [dev] Re: suggestions for 0.20.0
Posted by Peter Amstutz <pe...@curoverse.com>.
I have written a fairly complete Azure ARM compute driver for
libcloud, which is available here (including the ability to do OAuth2
authentication to get an API token).
https://github.com/curoverse/libcloud
I would like to upstream it, but haven't had the resources to write
tests, so I've just been sitting on it for the last couple of months
(we are using it internally). Perhaps I should go ahead and make a
pull request, to get code review feedback?
By the way, ARM templates are just a thin layer on top of the REST
API. Templates are useful for scripted deployment, but the underlying
ARM JSON REST API is a mostly straightforward match for libcloud
(with some gotchas that I can go into if anyone is interested.)
Thanks,
Peter
On Sat, Oct 24, 2015 at 8:10 AM, Richard Conway <ri...@elastacloud.com> wrote:
> Couple of points (since I contributed to the original Azure compute driver)
>
> 1. The majority of users and enterprises using Azure are still using what Microsoft term "Classic" mode. This isn’t going away anytime soon although it is compounded by the fact that ARM and Classic are mutually exclusive such that you can't use "v1" with "v2" resources.
> 2. ARM itself is not a great fit for libcloud so it needs to be carefully thought about. It ties vnets, storage and compute together and makes certain things bound to one another (through ARM templates). In effect it does much of the job that you would be doing programmatically in libcloud.
>
> That said it's probably worthwhile ADDING (not replacing) oauth through Microsoft and work and school accounts. Many people are still using .publishsettings files to generate X509 so a replacement would cause issues with many users current workflow. Microsoft, themselves, still support both through Powershell CmdLets with a Switch-Mode CmdLet (although this may be deprecated soon in favor of something simpler).
>
> Cheers,
>
> Richard
>
> -----Original Message-----
> From: anthony shaw [mailto:anthony.p.shaw@gmail.com]
> Sent: Friday, October 23, 2015 11:13 PM
> To: dev@libcloud.apache.org; dev <de...@libcloud.apache.org>
> Subject: Re: [dev] Re: suggestions for 0.20.0
>
> Wrt item 1, we wouldn't need to add it as a dependency, you can just use the requests library to get the token for oauth. That's all they are doing. And their SDK looks pretty incomplete so it wouldn't be a good dependency. I'm happy to do that task, I've got lots of accounts on azure to test on and plenty of VMs. It's probably time I contributed to another driver!
> Wrt the backup, I'll send a comparison of the features in azure, Rackspace and dimension data to help with a base class. I'd got that somewhere anyway from prior research building our own service. I would imagine some of the other providers have also. Ant
>
> Sent from Outlook
>
>
>
>
> On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" <to...@apache.org> wrote:
>
>
>
>
>
>
>
>
>
>
> All good stuff.
>
> 1. As far as depending on the 3rd party libraries / packages goes - in the past we avoided that because it's harder to test it and make sure it works under all the Python versions we support.
>
> 2. Introducing a new API usually requires more work which includes a proposal to the mailing list and a prototype / initial implementation with at least 2 drivers (3 are better).
>
> The reason for at least 2 drivers is to make sure that the base API and implementation is indeed generic (as much as possible) and not biased towards a single provider...
>
> 3. Yeah, some cleaning is in order. Would be good to check which providers are now dead and remove those drivers (HP just announced sun set of their public cloud offering so in a couple of months we can get rid of that driver as well).
>
> On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
> wrote:
>
>> WRT item 1)
>>
>> Microsoft have already implemented this approach in the
>> azure-python-sdk pypi.
>>
>>
>> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagem
>> entauthentication.html
>>
>>
>> Ant
>>
>> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
>> wrote:
>>
>> > I had some suggestions for the next version,
>> >
>> >
>> > 1) Azure Driver:
>> > * Only supports the 'old' way of authenticating, continue this
>> > method
>> > * Offer the new Azure AD/OAuth method as a secondary option for
>> > instantiating a driver -
>> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
>> > This is Microsoft's recommended approach and it's probably a matter
>> > of time until they stop supporting certificates (according to an 'insider').
>> >
>> > 2) A Backup Driver type:
>> >
>> > I'm looking at adding support for the DD Cloud Backup service and it
>> > doesn't really fall under the compute functionality. There are a few
>> other
>> > providers offering very similar functionality on the market
>> >
>> > Azure
>> > Rackspace
>> > Dimension Data
>> >
>> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide
>> > /
>> > Azure
>> > https://azure.microsoft.com/en-us/services/backup/
>> >
>> > This would be very similar to the DNS driver type.
>> >
>> > 3) Removing the opsource driver, this is superseded by the Dimension
>> > Data driver and has been for a while now.
>> >
>> > Ant
>> >
>>
RE: [dev] Re: suggestions for 0.20.0
Posted by Richard Conway <ri...@elastacloud.com>.
Couple of points (since I contributed to the original Azure compute driver)
1. The majority of users and enterprises using Azure are still using what Microsoft term "Classic" mode. This isn’t going away anytime soon although it is compounded by the fact that ARM and Classic are mutually exclusive such that you can't use "v1" with "v2" resources.
2. ARM itself is not a great fit for libcloud so it needs to be carefully thought about. It ties vnets, storage and compute together and makes certain things bound to one another (through ARM templates). In effect it does much of the job that you would be doing programmatically in libcloud.
That said it's probably worthwhile ADDING (not replacing) oauth through Microsoft and work and school accounts. Many people are still using .publishsettings files to generate X509 so a replacement would cause issues with many users current workflow. Microsoft, themselves, still support both through Powershell CmdLets with a Switch-Mode CmdLet (although this may be deprecated soon in favor of something simpler).
Cheers,
Richard
-----Original Message-----
From: anthony shaw [mailto:anthony.p.shaw@gmail.com]
Sent: Friday, October 23, 2015 11:13 PM
To: dev@libcloud.apache.org; dev <de...@libcloud.apache.org>
Subject: Re: [dev] Re: suggestions for 0.20.0
Wrt item 1, we wouldn't need to add it as a dependency, you can just use the requests library to get the token for oauth. That's all they are doing. And their SDK looks pretty incomplete so it wouldn't be a good dependency. I'm happy to do that task, I've got lots of accounts on azure to test on and plenty of VMs. It's probably time I contributed to another driver!
Wrt the backup, I'll send a comparison of the features in azure, Rackspace and dimension data to help with a base class. I'd got that somewhere anyway from prior research building our own service. I would imagine some of the other providers have also. Ant
Sent from Outlook
On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" <to...@apache.org> wrote:
All good stuff.
1. As far as depending on the 3rd party libraries / packages goes - in the past we avoided that because it's harder to test it and make sure it works under all the Python versions we support.
2. Introducing a new API usually requires more work which includes a proposal to the mailing list and a prototype / initial implementation with at least 2 drivers (3 are better).
The reason for at least 2 drivers is to make sure that the base API and implementation is indeed generic (as much as possible) and not biased towards a single provider...
3. Yeah, some cleaning is in order. Would be good to check which providers are now dead and remove those drivers (HP just announced sun set of their public cloud offering so in a couple of months we can get rid of that driver as well).
On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
wrote:
> WRT item 1)
>
> Microsoft have already implemented this approach in the
> azure-python-sdk pypi.
>
>
> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagem
> entauthentication.html
>
>
> Ant
>
> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
> wrote:
>
> > I had some suggestions for the next version,
> >
> >
> > 1) Azure Driver:
> > * Only supports the 'old' way of authenticating, continue this
> > method
> > * Offer the new Azure AD/OAuth method as a secondary option for
> > instantiating a driver -
> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> > This is Microsoft's recommended approach and it's probably a matter
> > of time until they stop supporting certificates (according to an 'insider').
> >
> > 2) A Backup Driver type:
> >
> > I'm looking at adding support for the DD Cloud Backup service and it
> > doesn't really fall under the compute functionality. There are a few
> other
> > providers offering very similar functionality on the market
> >
> > Azure
> > Rackspace
> > Dimension Data
> >
> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide
> > /
> > Azure
> > https://azure.microsoft.com/en-us/services/backup/
> >
> > This would be very similar to the DNS driver type.
> >
> > 3) Removing the opsource driver, this is superseded by the Dimension
> > Data driver and has been for a while now.
> >
> > Ant
> >
>
Re: [dev] Re: suggestions for 0.20.0
Posted by anthony shaw <an...@gmail.com>.
Wrt item 1, we wouldn't need to add it as a dependency, you can just use the requests library to get the token for oauth. That's all they are doing. And their SDK looks pretty incomplete so it wouldn't be a good dependency.
I'm happy to do that task, I've got lots of accounts on azure to test on and plenty of VMs. It's probably time I contributed to another driver!
Wrt the backup, I'll send a comparison of the features in azure, Rackspace and dimension data to help with a base class. I'd got that somewhere anyway from prior research building our own service. I would imagine some of the other providers have also.
Ant
Sent from Outlook
On Fri, Oct 23, 2015 at 2:34 PM -0700, "Tomaz Muraus" <to...@apache.org> wrote:
All good stuff.
1. As far as depending on the 3rd party libraries / packages goes - in the
past we avoided that because it's harder to test it and make sure it works
under all the Python versions we support.
2. Introducing a new API usually requires more work which includes a
proposal to the mailing list and a prototype / initial implementation with
at least 2 drivers (3 are better).
The reason for at least 2 drivers is to make sure that the base API and
implementation is indeed generic (as much as possible) and not biased
towards a single provider...
3. Yeah, some cleaning is in order. Would be good to check which providers
are now dead and remove those drivers (HP just announced sun set of their
public cloud offering so in a couple of months we can get rid of that
driver as well).
On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw
wrote:
> WRT item 1)
>
> Microsoft have already implemented this approach in the azure-python-sdk
> pypi.
>
>
> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagementauthentication.html
>
>
> Ant
>
> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw
> wrote:
>
> > I had some suggestions for the next version,
> >
> >
> > 1) Azure Driver:
> > * Only supports the 'old' way of authenticating, continue this method
> > * Offer the new Azure AD/OAuth method as a secondary option for
> > instantiating a driver -
> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> > This is Microsoft's recommended approach and it's probably a matter of
> > time until they stop supporting certificates (according to an 'insider').
> >
> > 2) A Backup Driver type:
> >
> > I'm looking at adding support for the DD Cloud Backup service and it
> > doesn't really fall under the compute functionality. There are a few
> other
> > providers offering very similar functionality on the market
> >
> > Azure
> > Rackspace
> > Dimension Data
> >
> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide/
> > Azure
> > https://azure.microsoft.com/en-us/services/backup/
> >
> > This would be very similar to the DNS driver type.
> >
> > 3) Removing the opsource driver, this is superseded by the Dimension Data
> > driver and has been for a while now.
> >
> > Ant
> >
>
Re: [dev] Re: suggestions for 0.20.0
Posted by Tomaz Muraus <to...@apache.org>.
All good stuff.
1. As far as depending on the 3rd party libraries / packages goes - in the
past we avoided that because it's harder to test it and make sure it works
under all the Python versions we support.
2. Introducing a new API usually requires more work which includes a
proposal to the mailing list and a prototype / initial implementation with
at least 2 drivers (3 are better).
The reason for at least 2 drivers is to make sure that the base API and
implementation is indeed generic (as much as possible) and not biased
towards a single provider...
3. Yeah, some cleaning is in order. Would be good to check which providers
are now dead and remove those drivers (HP just announced sun set of their
public cloud offering so in a couple of months we can get rid of that
driver as well).
On Fri, Oct 23, 2015 at 1:50 AM, anthony shaw <an...@gmail.com>
wrote:
> WRT item 1)
>
> Microsoft have already implemented this approach in the azure-python-sdk
> pypi.
>
>
> https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagementauthentication.html
>
>
> Ant
>
> On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw <an...@gmail.com>
> wrote:
>
> > I had some suggestions for the next version,
> >
> >
> > 1) Azure Driver:
> > * Only supports the 'old' way of authenticating, continue this method
> > * Offer the new Azure AD/OAuth method as a secondary option for
> > instantiating a driver -
> > https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> > This is Microsoft's recommended approach and it's probably a matter of
> > time until they stop supporting certificates (according to an 'insider').
> >
> > 2) A Backup Driver type:
> >
> > I'm looking at adding support for the DD Cloud Backup service and it
> > doesn't really fall under the compute functionality. There are a few
> other
> > providers offering very similar functionality on the market
> >
> > Azure
> > Rackspace
> > Dimension Data
> >
> > https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide/
> > Azure
> > https://azure.microsoft.com/en-us/services/backup/
> >
> > This would be very similar to the DNS driver type.
> >
> > 3) Removing the opsource driver, this is superseded by the Dimension Data
> > driver and has been for a while now.
> >
> > Ant
> >
>
[dev] Re: suggestions for 0.20.0
Posted by anthony shaw <an...@gmail.com>.
WRT item 1)
Microsoft have already implemented this approach in the azure-python-sdk
pypi.
https://azure-sdk-for-python.readthedocs.org/en/latest/resourcemanagementauthentication.html
Ant
On Fri, Oct 23, 2015 at 10:37 AM, anthony shaw <an...@gmail.com>
wrote:
> I had some suggestions for the next version,
>
>
> 1) Azure Driver:
> * Only supports the 'old' way of authenticating, continue this method
> * Offer the new Azure AD/OAuth method as a secondary option for
> instantiating a driver -
> https://msdn.microsoft.com/en-us/library/azure/ee460782.aspx
> This is Microsoft's recommended approach and it's probably a matter of
> time until they stop supporting certificates (according to an 'insider').
>
> 2) A Backup Driver type:
>
> I'm looking at adding support for the DD Cloud Backup service and it
> doesn't really fall under the compute functionality. There are a few other
> providers offering very similar functionality on the market
>
> Azure
> Rackspace
> Dimension Data
>
> https://developer.rackspace.com/docs/cloud-backup/v1/developer-guide/
> Azure
> https://azure.microsoft.com/en-us/services/backup/
>
> This would be very similar to the DNS driver type.
>
> 3) Removing the opsource driver, this is superseded by the Dimension Data
> driver and has been for a while now.
>
> Ant
>