-
Notifications
You must be signed in to change notification settings - Fork 710
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
Discuss what to do with chart-repo and chartsvc #672
Comments
I think we have a couple of different options here:
We would have a tag reference in the chart values that we would update whenever we want to pull in a new version of chart-repo or chartsvc from the upstream Monocular repo. This would be the simplest option, but would give us the least control over releasing chart-repo and chartsvc as it would be tied to the release of Monocular.
We would be able to include the codebases in this repo and be able to build and release our own images for chart-repo and chartsvc, however this still has the drawbacks that code changes must go through the upstream Monocular repo and a reference must be updated in this repo (the submodule).
We could create a repo in the Helm org, e.g. helm/chart-sync-tools, where we can maintain chart-repo and chartsvc independently from both Monocular and Kubeapps. This will give us more flexibility in releasing new versions of both tools without tying it to a particular Monocular release. Drawbacks of this approach include an extra repository (more indirection/confusion for contributors) and processes we'll need to follow to start up a new Helm org repo.
To give us the greatest control over the tooling, we could maintain a fork of the codebases in this repo as well as the one in the upstream Monocular repo. This would allow us to make changes that might not make sense in the Monocular project, and allow us to continue releasing chart-repo and chartsvc with Kubeapps. I think we can avoid option 4 until/if there is a need to diverge from the Monocular project. Option 2 does not really give us much over option 1. Option 3 could be interesting, the new repo would be treated as a sub-project of Monocular, however it also might be a bit overkill. My take would be to go with option 1, we should have the ability to iterate on and release Monocular as often as we need, and it will be simpler to maintain. The chart-repo and chartsvc tools are also not as actively developed as other components in Kubeapps, so I don't think it will be too terrible to rely on upstream. |
@andresmgot @migmartri @arapulido WDYT? Any other ideas? |
The problem I see with option 1 is that we may need to do a release of the whole Monocular just for a needed change in the My preferred option is 3. IMO the cleanest solution is to treat those services as standalone products that have two users: Monocular and Kubeapps. That way the release process is independent of any of those products. We would use semver to properly notify changes. If a feature is not needed for Monocular we wouldn't need to update the image there for example (or the opposite). I know this is the most time consuming option so I am fine if we go with option 1 for the moment for that reason. |
To me, as both of you seem to suggest, option 1 and 3 are the two viable options. At first, I'd say that I prefer option 3 because of the releases burden described by @andresmgot, but it also adds some other issues like confusion on where to report issues, documentation and so on. If releasing Monocular often is not an issue, I'd go for option 1 for now, if the project becomes more difficult to handle in that aspect, we can always split them away like in option 3? |
Thanks for the feedback both, I agree with @migmartri that going down the option 1 route for now and then branching it out to a new repo if we feel the need to later on will be a good way to go. IMO, changes we'll make to chartsvc and chart-repo will be beneficial to both Monocular and Kubeapps (e.g. switching to the digest as a key for #659), so I would say it will make sense, most of the time, to do a release of the whole of Monocular for a change to one of these components. |
I agree 1 and 3 are the final options. How does the release of Monocular work today? Who is in charge of it? |
@arapulido I'm currently the only active maintainer on that project, I will be able to create releases there, as well as others on the OWNERS list: https://github.com/helm/monocular/blob/master/OWNERS |
We will move chart-repo and chartsvc out of the Kubeapps tree and into the https://github.com/helm/monocular as part of the Monocular 1.0 proposal. This issue is to decide how we approach this and continue releasing chart-repo and chartsvc as part of the Kubeapps bundle.
The text was updated successfully, but these errors were encountered: