shipper
shipper copied to clipboard
bookingcom
[WIP] Shipper uses Helm v3
This commit bumps Helm rendering engine version to v3 from v2. The new version is a major update and therefore is partially incompatible with the former head version. This commit brings the version to the latest stable one. Refs #228.
As kustomize is now a part of Helm distribution and https://github.com/helm/helm/pull/7259 is hopefully landing in 3.x, marking it as refs #101.
This change needs a careful testing cycle. As far as it went out of the release plan, no need to get it merged immediately.
Signed-off-by: Oleg Sidorov [email protected]
Overall, I'm quite positive on moving on with this change. Our preliminary tests indicate the baseline functionality works just fine.
The post render stuff is quite interesting! It's encouraging that the interface is pretty generic (PostRenderer.Run takes a byte slice and returns a byte slice), so it seems like a great way to think about using Kustomize or any other layering patch implementation to let people tune charts just in time.
However, reading the implementation, it looks the hook was implemented as part of the CLI command (https://github.com/helm/helm/blob/66292e5e240dd9ab3d28415d9b3946ca8efc521e/pkg/action/install.go#L572).
In the long run I think it'd be great to delegate the business of rendering and installing manifests, but looking around action.go linked above I think it'd be a little tricky to do so and maintain lifecycle control like we have now (clear split between rendering and installation, for example). What do you think?
@kanatohodets The current progress of kustomize adoption in Helm seems to be at the very early stage and I'm quite sure it might transform into something completely different-looking in the future. By now, we are aiming to commit a transition towards Helm v3 and ensure Shipper works stable. Opening this opportunity of building in some kustomize-based rendering sub-pipeline is not the major goal of this PR but clearly an implication on some future potential use. From that perspective, I see no concerns in switching and as you can see I have no proposal for the user-facing handle to make rendering customization work :-)
