Making admin commands work for serial console when the VM has a custom storage account attached

[Talos10]

The bug initially came as a customer complaining that sending NMIs (non-maskable interrupts) to their VMs through the CLI did not work. After further investigation, it was found that having the VM switch from a custom to a managed storage account made the NMI sendable through the CLI. After more investigation, it was found that both custom and managed storage accounts worked when sending the NMI through the Azure Portal, and so after digging through the code, it was found that the reason for that was because the bearer token is not being sent by the cli to the connector container which means that the logic to make the host connect by storing the blob does not get executed. However, since the Azure Portal does send the token, then the code behaved as expected.

When looking at the container logs, the error showing up is that the host has not connected and so there is no one to handle the admin command that is being set and that is why the loading icon loads for a few minutes after sending the cli command (before abruptly ending).

The fix is to ensure that for custom accounts, the bearer token is being sent by the cli.

---

This checklist is used to make sure that common guidelines for a pull request are followed.

Related command

az cli serial-console ...

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
• Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
• My extension version conforms to the Extension version schema

For new extensions:

• My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish

There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

[azure-client-tools-bot-prd]

️✔️Azure CLI Extensions Breaking Change Test

️✔️Non Breaking Changes

[yonzhan]

Thank you for your contribution! We will review the pull request and get back to you soon.

[github-actions]

The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR.

Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions).
After that please run the following commands to enable git hooks:

pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>

[github-actions]

• For more info about extension versioning, please refer to Extension version schema

[Talos10]

@microsoft-github-policy-service agree company="Microsoft"

[necusjz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[Talos10]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 9479 in repo Azure/azure-cli-extensions

[Talos10]

@necusjz I think the builds should pass now if you retrigger them. I updated the test recordings that were making the builds fail.

[yonzhan]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[azclibot]

[Release] Update index.json for extension [ serial-console-1.0.0b3 ] : https://dev.azure.com/msazure/One/_build/results?buildId=147046356&view=results

[Talos10]

@necusjz Thank you for approving the PR! I had two questions about the whole devops process if that's alright.

1. When a PR is merged, the code automatically get released to prod (aka anyone using the extension has immediate access to the changes), correct? That's what I was told and I verified it myself since I tested my changes in prod after the merge, but I wanted to confirm with you as well that it wasn't a one-off and that this is always the case.
2. Someone from my team told me that the usual process when making a PR for az cli extensions was to first make the PR, have it reviewed and approved by someone on my team, then submit an R2D (since as soon as the PR is merged, the code is deployed to prod and R2Ds are needed for prod changes) and once the R2D is approved, then I could merge the PR. Is that the usual process you're accustomed to? Am I asking because I don't think anyone from my team had the time to review the PR and I did not have the time to raise an R2D and I saw that you merged my PR. There is nothing to worry about here since I tested my changes and they worked, but I wanted to ask if you were able to review my changes adequately given how many extensions/active PRs there are in this repo or if you assumed that my code was already peer-reviewed by the time that I made this PR.

Thanks a lot for your answers in advance!