New Microsoft Azure docker-machine driver

[ahmetb]

The new driver uses Azure Resource Manager APIs and offers a lot
more functionality compared to the old Azure driver. It is also
easier to authenticate and does not require user to create and place
certificate files. It only has a single required argument.

This is a breaking change: The new driver cannot work with machines
created with the older Azure driver and vice versa (as the APIs are
entirely different and resources are not shared between old/new azure
APIs).

The new driver addresses many issues about the azure driver reported
so far. Please read azure.md for docs about what's new.

This resolves #2742, resolves #1368, resolves #1142, resolves #2236,
resolves #2408, resolves #1126, resolves #774.

[nathanleclaire]

Which pieces of info are you missing here? On operations subsequent to create invocation, []byte from disk (config.json file) for driver will be unmarshaled into the struct directly, after the NewDriver function returns the initial struct, so it's not unexpected behavior.

[ahmetb]

@nathanleclaire I believe from what I tried, assigning certain objects during various points of this object's lifetime caused those instances to get lost. So it is not very clear to me at which exact point this config data gets marshaled and unmarshaled.

For instance, when I assign something here during create or pre-create, I saw that it totally gets lost during GetState/GetIP calls that occur later during the machine creation.

For quite a moment I thought maybe it is reinitializing the driver for those calls –but this is not an external driver, I was assuming it'd be in-process and there'd be only a single azure Driver instance throughout the lifetime of a docker-machine execution process; but it appears like due to RPC that's not the case.

I'm still not clear about inner workings of RPC model in docker-machine. I found my way around it but guess I still appreciate any explanation about lifecycle of Driver instance and when/how config gets (un)marshaled.

[nathanleclaire]

Made a few comments / questions but it's looking really good! Thanks for taking the initiative on this.

My general feeling is that I want to err on the side of merging this soon, and testing-as-we-go.

Also, with this branch of development, we're breaking backwards compatibility with old azure-created hosts completely, no? What's our transition plan?

[ahmetb]

@nathanleclaire I have the same opinion, I feel like it's in a usable state already.

Also, with this branch of development, we're breaking backwards compatibility with old azure-created hosts completely, no? What's our transition plan?

It is completely breaking (I have a comment about this in azure.md), there's no way you could even delete Azure machines created with the old driver; and that's because new Azure APIs are completely different and they don’t share any data. There's not much we can do about that other than making the docs better, I believe.

[ahmetb]

Sorry about this gordon noise. Protip: never push this "Update branch" button:

[ppadala]

It will be good to add a comment saying that, if someone wants to automate using docker-machine, they will have to provide publishsettings or subscriptionID, cert pair

[ahmetb]

Not anymore. Please look at the azure.md as a whole, not a diff. The new driver has nothing to do with the old driver, including the authentication model. It's beneficial to not think of the old Azure driver here at all. The new Azure APIs are a complete paradigm change in pretty much every aspect.

[nathanleclaire]

Is there any way to provide users a script or something that will migrate old versions of VMs created with the azure driver to this new driver? I'm starting to feel that I was a bit hasty with the merge removing the old driver and considering reverting it. Our deprecation policy is two releases so dropping support for a driver so abruptly has me concerned.

Let's talk about options to preserve and migrate existing azure VMs, since I'm sure at least some are out there. Maybe we can rename and include the existing driver as azure-legacy and bump config versions to do a migration of existing azure VMs (at config version 3) to have the driver name azure-legacy. Then over time, we will phase it out completely.

[ahmetb]

@nathanleclaire fair point. I was not aware of two versions policy, though I remember asking about it in our earlier conversations (:P).

A migration is just not possible. What I can offer is, maybe we keep azure driver around for another release and call this `azure-new then fix it later?

Basically if you ask me, I don't think people will be disappointed if we break with a nice error message saying "hey this version doesn't support old Azure VMs, please go back to v0.6.0", but up to you.

[ahmetb]

Or we can call this azure and when an old VM is triggered, we can offer a link to migration script that modifies existing VMs to azure-old. Feel free to pick one of these solutions @nathanleclaire, I will happily implement.

[nathanleclaire]

So, consensus on our end after talking with @dmp42 is that:

1. We are fine with moving forward using the new Azure driver, however-
2. Any existing azure machines machines should error out when any operation with the next released version of Machine (after merging this code in) is attempted. A "deprecated" type warning suggesting the user switch to the new model in order to use the new version of Machine should be shown.
3. Likewise, no destructive updates to the config.json should be made. It must be possible for the user to use Machine 0.6.0 to tie up loose ends (e.g. docker-machine rm) with the legacy driver before moving to the new one.
4. We will also put a notice about this in the release notes.

How does that sound? Are you willing to work with us on verifying that the above works as expected? I've not had much success with the legacy Azure driver in the past unfortunately. The tricky bit in the above will be preventing damage to the config.json -- it gets loaded/saved in quite a few places.

[ahmetb]

@nathanleclaire That sounds good. It looks like I just have to make sure we don't damage config.json and terminate early when we detect the old azure driver (and tell users about deprecation and downgrading to rm old machines).

Actually this new driver already errors out and doesn't damage config.json for old Azure VMs but I will make the error clearer.

[nathanleclaire]

Actually this new driver already errors out and doesn't damage config.json for old Azure VMs but I will make the error clearer.

OK sounds great. Thanks Ahmet.

[ahmetb]

@dgageot just pushed a commit fixing this. Sorry for the trouble. API folks are looking at why some namespaces might be returned as lowercase for some users. Thanks for reporting this.

[dgageot]

LGTM

[ahmetb]

@dgageot thanks for reviewing and testing, I really appreciate we found that bug before the release. We currently don't know how many users are getting this different uppercase/lowercase output from the APIs but we got it covered for now.

[dgageot]

ping @nathanleclaire

[nathanleclaire]

Going to take it for a test drive, then most likely merge. cc @londoncalling for docs review; if there are any problems, I suggest we open and issue and do a follow-up PR.

[londoncalling]

The first time you try to ...etc.

[londoncalling]

I made some wording corrections in inline comments for azure.md, but haven't had time to test the driver yet. If you like, I can update for flow of the text in the azure.md file after this is merged. There's just a lot of nitpicky things I would change throughout about the wording.

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "azure-arm" git@github.com:ahmetalpbalkan/machine.git somewhere
$ cd somewhere
$ git rebase -i HEAD~7
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "azure-arm" git@github.com:ahmetalpbalkan/machine.git somewhere
$ cd somewhere
$ git rebase -i HEAD~7
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[GordonTheTurtle]

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "azure-arm" git@github.com:ahmetalpbalkan/machine.git somewhere
$ cd somewhere
$ git rebase -i HEAD~7
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[ahmetb]

@londoncalling thanks for reviewing, just addressed docs comments in a separate commit (9fd035e)

[nathanleclaire]

@ahmetalpbalkan How exactly does one get an Azure subscription ID? This screen doesn't have any and can't figure out how to get one.

[ahmetb]

@nathanleclaire hmm that's weird I didn't know you could have an Azure account without having a subscription. Try http://azure.com/free to get a Trial Subscription.

[nathanleclaire]

Guess I had a free trial one that expired so maybe Azure got confused. I am starting the whole funnel again from that link you sent me -- think this should work.

[nathanleclaire]

Create and other expected operations works smoothly for me (and create is miles ahead of the old driver in terms of user experience -- excellent job!).

LGTM

Thanks and congratulations on all your good work Ahmet and everyone else involved in bringing this to fruition.

[ahmetb]

@nathanleclaire @dgageot It's very delightful to hear all these, thank you for taking time to review this as well. I will be sending the improvements incrementally.

[ppadala]

Great work @ahmetalpbalkan! I have started rebasing my change. Also, filed an issue based on our discussion above about automation.

[edevil]

Great work!