Upgrade Flux from v1 to v2 (Gitops)

[sivaramsk]

The flux v1 version being used by BAF has been on maintenance mode for sometime. Flux v2 is a logical choice as BAF is already using v1 and there migration path described in the project from v1 to v2.

Additional Context:

• Flux v1 is in maintenance mode fluxcd/flux#3320
• https://toolkit.fluxcd.io/guides/helm-operator-migration/

[sivaramsk]

@suvajit-sarkar - if no one has taken this ticket, I can do some initial work and add more details to the ticket before discussing it in the next sprint. Can you assign this ticket to me?

[suvajit-sarkar]

hi @sivaramsk any updates on this ?

[sivaramsk]

Sorry @suvajit-sarkar - I started working on this and got side tracked with my day work. I had a list of questions on the upgrade, will update the ticket shortly with those and will also join your next Sprint planning to discuss how to proceed with this.

[sivaramsk]

One of the major question that came to me was - how much of backward compatibility should I think about when I work on this? Since I have not really tried upgrading any of my cluster, how should I handle the backward compatibility?

From the testing I did to understand V2, it looks to be quite different (at least to my current understanding), so, it might be a bit easier to do this as breaking change rather than trying to make it compatible with older version. Another approach I was thinking is, may be we can have both the version supported and control it from network.yaml - have a flag to indicate whether you want to stick with the v1, but that would increase the testing effort to test both v1 and v2.

This exactly the place I stopped my work last time when I started, I would appreciate your feedback on how to proceed on this.

[sownak]

@sivaramsk Thanks for getting back. For major upgrades, we do not maintain older version. So, if v2 is the way forward, we will only maintain that. And as this is a big change, i.e. all platforms need to be tested, we can create a long running feature branch and when all platforms are tested only then merge to develop/master.

[sivaramsk]

Thanks @sownak. Will update this ticket on my plan on how approach this feature.

[sivaramsk]

In the flux v1 installation, we add the the helm chart "fluxcd https://charts.fluxcd.io", but have all the yaml files stored locally and point to them during the helm install, why do we have to store the flux helm install files in the BAF code?

KUBECONFIG={{ kubeconfig_path }} helm upgrade --install flux-{{ network.env.type }} {{ playbook_dir }}/../../../platforms/shared/charts/flux --namespace default --set git.secretName=git-auth-{{ network.env.type }} --set rbac.create=true --set git.timeout=200s --set git.pollInterval=2m --set git.url='https://{{ git_username }}:{{ git_password }}@{{ git_repo }}' --set git.branch={{ git_branch }} --set git.label='sync-{{ network.env.type }}' --set git.path="{{ git_path }}"  --set registry.insecureHosts="{{ network.docker.url }}" --kube-context="{{ kubecontext }}"

[sivaramsk]

This feature looks much more complex than it initially looked to me. Following is a break up of tasks I am considering for this feature broadly.

1. Installation of Flux V2 by adding the flux binary in the baf-build container and
2. Bootstrap the flux v2 in to the kubernetes cluster through the flux binary. (The folder structure used in v2 seems lot difference from v1, so, I am yet to fully understand the changes needed to make it work for BAF folder structure).
3. Migrate Hyperledger Fabric code to Flux V2.

[sivaramsk]

@sownak @suvajit-sarkar can someone help in creating a new branch for this feature. I could only raise the PR against created branches, but not create a new branch itself.

[suvajit-sarkar]

@sivaramsk have created a feature branch : feature/flux-v2, you can use that

[sivaramsk]

This feature looks a bit more complex than it initially looked to me. I was able to install and bootstrap the flux_v2 in to the environment, but the biggest issue comes from the flux's use of kustomize internally. Kustomize looks not very straight forward to use when you have to create the yamls dynamically. Each folder that is used for deployment has a file called kustomization.yaml and when you create a new folder for deployment like "releases/new_release/org1/peer/release.yaml" - this folder have to be explicitly added to the root folder's kustomization.yaml.

I guess I have to write a wrapper script to add the new folder in to the kustomization.yaml to make it work. Will keep updating here on the progress.

[sivaramsk]

Sorry guys, my bandwidth did not allow me work on this at all. Can someone take this over for me please?

@suvajit-sarkar

[hoang-innomize]

Would love if we have this change implemented. Looking forward to hearing if we have someone can support on this feature

[suvajit-sarkar]

Sure, no problem.. will check if we can prioritize this in the coming sprint

[suvajit-sarkar]

Closing this issue, flux v2 is on release please use latest branches for flux v2 support