-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Flux from v1 to v2 (Gitops) #1283
Comments
@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? |
hi @sivaramsk any updates on this ? |
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. |
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. |
@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. |
Thanks @sownak. Will update this ticket on my plan on how approach this feature. |
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?
|
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.
|
@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. |
@sivaramsk have created a feature branch : feature/flux-v2, you can use that |
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. |
Sorry guys, my bandwidth did not allow me work on this at all. Can someone take this over for me please? |
Would love if we have this change implemented. Looking forward to hearing if we have someone can support on this feature |
Sure, no problem.. will check if we can prioritize this in the coming sprint |
Closing this issue, flux v2 is on release please use latest branches for flux v2 support |
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:
The text was updated successfully, but these errors were encountered: