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

Proposal: Move the OpenCost UI into a separate repository #2468

Closed
mattray opened this issue Jan 24, 2024 · 7 comments · Fixed by #2741
Closed

Proposal: Move the OpenCost UI into a separate repository #2468

mattray opened this issue Jan 24, 2024 · 7 comments · Fixed by #2741
Labels
E3 Estimated level of Effort (1 is easiest, 4 is hardest) opencost OpenCost issues vs. external/downstream P3 Priority (P0 is highest, P4 is lowest)

Comments

@mattray
Copy link
Collaborator

mattray commented Jan 24, 2024

The OpenCost UI releases are currently tied to releasing OpenCost. Separating them would allow independent releases, separate maintainers, and different build and testing frameworks. The UI accesses the OpenCost API, so they're not really tightly coupled by any means. Kubecost Engineering is not usually involved with the OpenCost UI, this would potentially open it up to more external contributors and a quicker release cadence.

@mattray mattray added opencost OpenCost issues vs. external/downstream E3 Estimated level of Effort (1 is easiest, 4 is hardest) P3 Priority (P0 is highest, P4 is lowest) labels Jan 24, 2024
@dwbrown2
Copy link
Collaborator

I've not really seen this done with other CNCF projects that have similar components, e.g. Prometheus. Are there examples that you feel the project should aim to follow?

@mattray
Copy link
Collaborator Author

mattray commented Jan 26, 2024

Another point for splitting, we merged a CVE dependency fix for the UI that won't ship until we do an OpenCost release. Splitting them would allow independent releases.

@mattray
Copy link
Collaborator Author

mattray commented Apr 19, 2024

Another benefit pointed out by @cliffcolvin would be we can have separate maintainers for the UI and the OpenCost cost model. It will reduce the number of issues for opencost/opencost and make working on the UI more accessible. The default installation would still use both containers, but we could release them independently as necessary.

@sntxrr
Copy link

sntxrr commented Apr 19, 2024

I am very much pro split. Having these decoupled would be very helpful for onboarding different skill sets from the community

@brito-rafa
Copy link
Contributor

I support the split.

@asdfgugus
Copy link

I support the split as well.

@cliffcolvin
Copy link
Member

I think this is a pretty good move @dwbrown2. There are some benefits here and no change to end-user experience. The docker containers are already split and have been as long as I've been around and helm users will still deploy a combined helm package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E3 Estimated level of Effort (1 is easiest, 4 is hardest) opencost OpenCost issues vs. external/downstream P3 Priority (P0 is highest, P4 is lowest)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants