@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 <[email protected]> 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:[email protected]] > Sent: Monday, October 26, 2015 1:59 PM > To: [email protected] > 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 <[email protected]> > 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:[email protected]] > > Sent: Friday, October 23, 2015 11:13 PM > > To: [email protected]; dev <[email protected]> > > 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" <[email protected]> > 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 > >> > > >> >
