You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the workflow for onboarding new Azure users, the customers get to choose between Azure Arc, or AKS. They don't really create the cluster in the VScode editor with the GitOps extension, so in reality I think by the time they connect a cluster they have already chosen, (now except with #218 they may also revert and choose Generic Flux instead.)
If they are not using #218 then they will be depending on the AKS addons manager which requires opting into some features via the Azure APIs and/or az CLI. Currently they must opt into these manually, if they are looking in the right place when things fail the first time, they may encounter error messages with links guiding them to install, but they are mixed with output in an editor view, rather than presented in a workflow: this interface is not ideal.
It would be preferable to have a pop-up workflow like the "Flux CLI is not installed" workflow where the editor extension enables.
Separate issue, or maybe it's the same issue, the UI for inputting subscription ID and resource group ID is somewhat less than ideal. (#265)
The experience should ideally be like "click next... next... next..." and your addons get installed, since everything can be enabled through the CLI, and the workflow already provides a mechanism for us to provide our resource group id and subscription id for connection through to the addons manager. Sometimes one of these steps fails due to the attached account's permissions.
Assuming that you have attached from a new, root-level Azure portal account with no account restrictions, it should not fail the addons installation or prompt with any errors in the terminal/output windows, it should just work and you land at the "GitOps Enabled" step whichever pathway is chosen. Another possibility is that your account is restricted from installing the Flux addon, then someone with a root-level permission will have to grant you access to that capability. It's not clear where that is documented.
The text was updated successfully, but these errors were encountered:
kingdonb
changed the title
Progress helpers when they fail should have graceful degradation
Azure onboarding and cluster detection based on metadata
Aug 23, 2022
We've changed the scope of this issue after doing some experiments. It should always be possible to detect the cluster information through the Azure AKS APIs and we can generally expect this cluster metadata collection to be an invisible process, where everything goes smoothly and as long as there is only one cluster in your account, you would click "next" ... "next" ... "next" and experience the Flux extension getting installed to completion with no friction or hard decisions to make.
I'm enthusiastic that we will close this issue some time soon, likely well before the 0.22 milestone, which we're expecting to have rounded out all the rough edges on AKS,
And it should come with a more thorough milestone plan or roadmap, too. 🚀!
In the workflow for onboarding new Azure users, the customers get to choose between Azure Arc, or AKS. They don't really create the cluster in the VScode editor with the GitOps extension, so in reality I think by the time they connect a cluster they have already chosen, (now except with #218 they may also revert and choose Generic Flux instead.)
If they are not using #218 then they will be depending on the AKS addons manager which requires opting into some features via the Azure APIs and/or
az
CLI. Currently they must opt into these manually, if they are looking in the right place when things fail the first time, they may encounter error messages with links guiding them to install, but they are mixed with output in an editor view, rather than presented in a workflow: this interface is not ideal.It would be preferable to have a pop-up workflow like the "Flux CLI is not installed" workflow where the editor extension enables.
Separate issue, or maybe it's the same issue, the UI for inputting subscription ID and resource group ID is somewhat less than ideal. (#265)
https://docs.microsoft.com/en-us/cli/azure/k8s-configuration?view=azure-cli-latest
https://docs.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest
The experience should ideally be like "click next... next... next..." and your addons get installed, since everything can be enabled through the CLI, and the workflow already provides a mechanism for us to provide our resource group id and subscription id for connection through to the addons manager. Sometimes one of these steps fails due to the attached account's permissions.
Assuming that you have attached from a new, root-level Azure portal account with no account restrictions, it should not fail the addons installation or prompt with any errors in the terminal/output windows, it should just work and you land at the "GitOps Enabled" step whichever pathway is chosen. Another possibility is that your account is restricted from installing the Flux addon, then someone with a root-level permission will have to grant you access to that capability. It's not clear where that is documented.
The text was updated successfully, but these errors were encountered: