kolla-kubernetes build system

[kfox1111]

So, kolla-kubernetes currently has a set of python code used to build the helm packages. It would be nice to be more helm native, but would require some features in helm to accomplish that.

The code currently:

1. runs a local helm serv. helm dependency files can only currently reference remote repositories. If a relative local path could be used in the dependency file instead of a server, then it would not require a server to build. The deps also has a version field that is painful to maintain and local path variant could avoid needing. This would greatly simplify setting up a dev environment, as well as maintaining the code.
2. builds values.yaml file for each package due to there not being an easy way to share common values definitions from a library oriented subchart to the parent.

A third, upcoming issue, is dealing with versions. If we wanted to build packages for version X and version Y, its currently requires some python code or sed or something to go through the set of packages and update version in values.yaml's, requirements.yaml, and Charts.yaml. It would be nice to be able to specify a values.yaml file during the helm package command that will override individual values in the final package. It would be nice to be able to override the version in Chart.yaml from the cli. I think the versions in deps could be eliminated by local path's and then wouldn't be a problem.

[technosophos]

Thank you very much for this. Use cases like this help us steer the roadmap toward how people are actually using Helm.

[jascott1]

@kfox1111 , Im a big fan of this "local paths" feature and am happy to help there. Also, the version manipulation feature might start as a plugin to nail down the behavior/deps. I have a version manipulation plugin started but only supports x.y.z in charts and doesnt do all semver or other file types. This test shows some examples. I wrote it in bash to play with the plugin system, but would would be happy to work on a new version using a proper semver library and anointed language.

[kfox1111]

@jascott1 cool. I'll play with it and see what it can do. :)

we definitely want to use revisions I think, so only x.y.z would be too confining. would need something like x.y.z-1 or maybe x.y.z-a.b.c-1.

[technosophos]

Marking this as support since we don't have another category for it right now.

[technosophos]

Writing up how Kolla did its chart building would make a great blog post and addition to the docs for the project.

[jascott1]

@kfox1111 can we close this as we now have localpaths and import-values?

[kfox1111]

@jascott1: I think issue 1 and 2 are solved now. 3 is still there though.

[jascott1]

@kfox1111 Would you agree that a plugin would be tolerable for 3 since we are talking about a packaging / development workflow and not an end user install?

[kfox1111]

hmm... a plugin might work for the use case.

Its always nicer not to need plugins though.

[bacongobbler]

helm package --version sets the version on the chart and was introduced in #1706, finishing off all the asks in this issue. #2932 covers the last ask, so I'm closing this as resolved/duplicate.

In the future, let's try to open separate tickets for multiple feature requests. That way we can track individual tickets and close them more aggressively in the future. Thanks!