Skip to content
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

Closed
arapulido opened this issue Sep 24, 2018 · 7 comments
Closed

Discuss what to do with chart-repo and chartsvc #672

arapulido opened this issue Sep 24, 2018 · 7 comments

Comments

@arapulido
Copy link
Contributor

arapulido commented Sep 24, 2018

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.

@arapulido arapulido added size/M and removed size/M labels Sep 24, 2018
@prydonius
Copy link
Contributor

I think we have a couple of different options here:

  1. Rely on upstream images for chart-repo and chartsvc

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.

  1. Include chart-repo and chartsvc as a submodule

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).

  1. Propose that we maintain chart-repo and chartsvc in a separate repo in the Helm org

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.

  1. Maintain a fork of chart-repo and chartsvc

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.

@prydonius
Copy link
Contributor

prydonius commented Sep 27, 2018

@andresmgot @migmartri @arapulido WDYT? Any other ideas?

@andresmgot
Copy link
Contributor

andresmgot commented Sep 27, 2018

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 chartsvc that may not be needed there anyway. That may be good enough for the moment since as you say we are not developing new things for chart-repo and chartsvc right now but in the future we may.

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.

@migmartri
Copy link
Contributor

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?

@prydonius
Copy link
Contributor

prydonius commented Sep 27, 2018

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.

@arapulido
Copy link
Contributor Author

I agree 1 and 3 are the final options. How does the release of Monocular work today? Who is in charge of it?

@prydonius
Copy link
Contributor

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants