Azure auth is not idempotent

[ryanlovett]

az throws an error when you've already got the cluster creds. This is masked by CI but breaks when running on your own device.

$ hubploy deploy data100 hub staging
CloudName    IsDefault    Name         State    TenantId
-----------  -----------  -----------  -------  ------------------------------------
AzureCloud   True         data100-19s  Enabled abcde....
A different object named data100-fall-2019 already exists in contexts
Traceback (most recent call last):
  File "/home/ryan/.local/bin/hubploy", line 10, in <module>
    sys.exit(main())
  File "/home/ryan/.local/lib/python3.7/site-packages/hubploy/__main__.py", line 64, in main
    auth.cluster_auth(args.deployment)
  File "/home/ryan/.local/lib/python3.7/site-packages/hubploy/auth.py", line 150, in cluster_auth
    deployment, **cluster['azure']
  File "/home/ryan/.local/lib/python3.7/site-packages/hubploy/auth.py", line 227, in cluster_auth_azure
    '--resource-group', resource_group
  File "/usr/local/linux/anaconda3.7/lib/python3.7/subprocess.py", line 328, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['az', 'aks', 'get-credentials', '--name', 'data100-fall-2019', '--resource-group', 'data100-fall-2019']' returned non-zero exit status 1.
$ az aks get-credentials -n data100-fall-2019 -g data100-fall-2019
A different object named data100-fall-2019 already exists in contexts

[tjcrone]

Sorry I missed this question @ryanlovett. Did you solve it? Because a CI should start fresh, I don't think it should have the cluster in its context. Although maybe it could with caching. Locally you can use --overwrite-existing to overwrite (and with the newest versions of the Azure CLI, I think it defaults to asking). We could consider adding this flag to the Azure auth function if you think that is a good idea.