pivotal-cf/terraforming-azure

Update Azure CLI

siennathesane opened this issue · 8 comments

The Azure CLI 2.0 should be used, so all CLI commands need to be az, not azure.

Example:

if which "azure" > /dev/null; then
                :
        else
                echo "Could not find azure. Please \`brew install azure-cli\`."
                exit 1
        fi

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

Hey Mike. Thanks for bringing this to our attention. I wrapped up the 2.0 azure cli in a little go program if need to go through the steps again at any point and we will try to add it to this repo in a helpful way soon!

@genevievelesperance why didn't you use the go sdk? I'm not disparaging your effort, just seems easier to use the SDK rather than wrap the CLI. Thanks for getting the repo updated. Microsoft is trying to deprecate the 1.0 CLI, so I would recommend updating this issue sooner rather than later.

To use the sdk, you need to have an authentication config with service principal credentials (which you are using this tool to get).

Do you know of a way to use the sdk without a service principal?

I would absolutely prefer to use the sdk. Perhaps the sdk accepts credentials (and can handle single sign-on?) so that you can make requests without an sp already?

It looks like it might be possible with this config: https://github.com/Azure/go-autorest/blob/cab8279ba5cd5e165c58201f798712f2ec0f49d6/autorest/adal/config.go#L47-L81

(Edit) ^ that is used in combination with a service principal token to make client requests with the azure sdk for go.

Hey @mxplusb. We have swapped out the azure cli v1 script for instructions on how to use the az-automation go cli for creating the service principal.

Since there is still no clear way from the azure sdk maintainers on how to create a service principal with the sdk without already having service principal creds (which is the most common use case for this), we are going to continue using the cli, but v2.

Sounds good, whatever solves the problems best for you. :)