Periscope consumption strategy.

This issue is created to discuss aspects of key consuming tools which takes deployment file from periscope tool and deploy it, key ideas is to lock in the contract of usage for these consuming tools moving forward.

This discussion will also help in making sure that next release goes out smoothly.

Recently there is some good amount of work done to clean this repo and with the new changes to remove much of clutter and complexity there is decent amount of work went in to manage the yaml file, and using the kustomize concept.

This is again one of the honest appraisal of the situation between both tools: az-cli and vscode which consumes this tool. This discussion will help some of the key maintainers to voice their thoughts and the contract with existing tool which consume this tool. Discussion will also help in making it clear that if this tool co-exist with 2 different eco-system as coupled or totally de-coupled.

Latest clean up to Kustomize yaml file:

One of the key clean up took place was to handle declarative management of the one large *.yaml file into small more readable, and more consumable form. example: https://github.com/Azure/aks-periscope/blob/master/deployment/kustomization.yaml

Current consuming tool contract by use:

Currently in a prod, periscope tool utilises the aks-perisceop.yaml and with consuming tool (like az-cli, and vscode simply replace the storage name and sas key like in az-cli in line 118 https://github.com/Azure/aks-periscope/blob/master/deployment/aks-periscope.yaml#L118 and under the hood they run kubectl apply -f aks-persiceop.yaml to run this tool.

Essentially, I see as a viable solution because landing to the storage is one of the key aspect of this tool.

However we should lock in the usability contract for how we should use kustomize yaml moving forward:

Solutions:

Non-Breaking vs non-breaking vs dependent

There are 2 ways we could use it:

Option 1: Periscope repo owns this deployment contract and holds the deployment file. (Non-Breaking)

This is what the current existing behaviour is. So even with the use of Kustomize file we continue with this structure i.e. make aks-periscope.yaml out of the kustomize.yaml file and maintain at periscope repository. This way I believe do not change the consumption metrics for the az-cli and vscode.

Keep the consuming tool yaml under one directory structure but with in periscope repository. So, even though we are using kustomize file, we can keep equivalent to the aks-perisceop.yaml file within the periscope repo. For the more structural reasons we could move it to deployment/storage/aks-periscope.yaml

For example, in az-cli the collect command use direct deployment file to kubectl apply https://github.com/Azure/azure-cli-extensions/blob/main/src/aks-preview/azext_aks_preview/custom.py#L2073

Option 2: Consuming Tools handle the deployment file. (Breaking - so need consuming tool Co-ordination)

Under this option, the idea is that consuming tool will utilize the the existing kustomize file and maintain their own repository level deployment.yaml file. This will involve both az-cli and vscode to handle the kustomize file handling, it could either mean that consuming tool can do it using: kustomize build … or Kubectl kustomize ….kustmizedeployment > file.yaml and handle deployment. As discussed this will change the consumption metrics for the az-cli and vscode.

This will require changes both of these consuming tool, this also mean that we need careful planning.

For visibility and thoughts: @qpetraroia, @justindavies , @palma21 , @rzhang628

cc: @arnaud-tincelin, @davidkydd , @JunSun17

Thank you so much 🙏❤️
^Tats

Update 8th July:

Option 3: Dependent release Solution: Moving forward solution. (Respecting / Keeping Consuming Metrics Contract Intact for a time being)

(This solution focuses on the fact that other tool need transition time to port new changes)

We need transition for both consuming tools to adapt new changes, I also get a feeling from PM(s) that this tool co-exist with both az-cli and vscode i.e. the solution contract between 2 needs to stay but it is doable without breaking the change will be to respect the contract both tool have with aks-periscope.yaml and then once vscode and az-cli moved to new kustomize.yaml way we remove the old aks-periscope.yaml file in few months (with enough warning) - I believe az-cli release don't happen often and usability is restrictive.

One of the best solution is as follows:

• Keep kustomize solution, but also respect aks-periscope.yaml for next 3 - 4 months (Whatever is the best possible transition time for user to adapt) I think there are telemetry for it, for consuming Metrics.
• For underlying tools:
  • Consuming tools need to do 2 extra steps, to consume kustomize mechanism.
    • 1 - kubectl kustomize -f kustomizefile > localmaintained-aks-pericope-equivalent.yaml
    • 2 - Add storage to it: https://github.com/Azure/aks-periscope/blob/master/deployment/examples/kustomization_storage_account.yaml
    • OR - add we could add Storage to Kustomize ? (This will make it simpler)
    • 3 - kubectl apply -f localmaintained-aks-pericope-equivalent.yaml
• Once both tool does the above transition and we do not have any other dependency on the aks-periscope.yaml we remove it with proper communication in few month time.

Update 21st July

In current state of this repo the only backward compatibility changes we will need in the aks-periscope.yaml are as follows:

• https://github.com/Azure/aks-periscope/compare/master...Tatsinnit:backward-compatible-deployment?expand=1

Thanks, 🙏