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 <rich...@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.s...@gmail.com] > Sent: Friday, October 23, 2015 11:13 PM > To: dev@libcloud.apache.org; dev <dev@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 >> > >>
