Fix APIServerNaming issue - handle Ripple effect in AZ-CLI and VsCode. #99
Labels
breaking change 🚨
This label indicates that the work item contains breaking change.
discussion required 💬
enhancement 🏎
New feature or request
This issue is open to handle effect of a fix which will impact consuming tools, since the fix needs to be deployed to the consuming tools
az-cli
andvscode aks extension
https://github.com/Azure/aks-periscope#dependent-consuming-tools-and-working-contractWhat is the issue?
Part of the issue is that the periscope exporter formulates the container name from the APIServerName, but the way it does it makes the tool highly coupled to a
kubeconfig
hardocded file existing in AKS cluster. There are other issues which are documented here: #92 so from within the in-cluster scenarios there are various things which we cannot get information regarding clusters external kubeconfig, hence we need to handle it more elegantly and open the tool usage to wider scenarios.How we could fix that? (i.e. Solution)
Keep usage i.e. apiservername as the consuming tools used for the container name for azure storage but instead of internally doing it supply them from tool. like
kubectl cluster-info
can give much information and it could be passed on to the tool.Simplest organic solution is to supply the container from consuming tool. Implementation to remove the hard-coded kubeconfig path will look like this. #96
What next:
Before we change or publish the way container name works for storage with in periscope we need to make sure we open Connecting issues for
az-cli
andvscode
get their repos ready for this change hence not-break any of this toolToDo:Open tracking workitem against both theaz-cli
andvscode
regarding this impacting change.Thank you @qpetraroia for opening these tracking workitem for information and fix tracking.
Thanks.
cc: @arnaud-tincelin , @JunSun17 , @palma21 , @justindavies , @qpetraroia and @rzhang628 - FYI - Thanks heaps
The text was updated successfully, but these errors were encountered: