Support FluxHelmRelease resources in fluxd #1111
Conversation
This commit adds support for interpreting `FluxHelmRelease`s with a single image, provided in the field `Spec.Values.Image` -- i.e., the simplest of many different ways of providing image refs to a chart. The manifest update mechanism is stubbed out for now.
This mainly consists of making sure cluster/kubernetes/resource.FluxHelmRelease implements resource.Workload, and bumping the version of kubeyaml to a release that can update FluxHelmRelease resources. That enables all the requisite machinery, including verifying releases. An incidental change: throwing away the (`error`) return value of SetContainer when verifying hid a problem; so, don't ignore it.
- FluxHelmRelease test case - kubeyaml preserves quotes better now, so we can remove some of the test case cookery - use a specific version of kubeyaml from quay.io, instead of relying on there being a latest, library image
|
Hmm that scheme of naming the container for the path is not great -- for one thing, it could have slashes, and container names are |
| func (fhr FluxHelmRelease) Containers() []resource.Container { | ||
| values := fhr.Spec.Values | ||
| if imgInfo, ok := values["image"]; ok { | ||
| imgInfoStr := imgInfo.(string) |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
squaremo
force-pushed
the
feature/985-support-fluxhelmrelease
branch
from
9d49804 to
90a54f7
Compare
I came up with I don't think there's any such name that's going to be entirely self-explanatory. It would be nice to synthesise a name that's meaningful to the chart, but we don't have the chart to hand, and using the path seems unreliable (what if someone supplies |
Settled on |
When interpreting FluxHelmRelease (FHR) resources as workloads, we have to synthesise a set of (zero or one) containers from the information given in each FHR. The simplest way to do this is to expect a field in the `values` for the release, called `image`, giving an image ref to be interpolated into the chart's templates somewhere (we don't care where). Rather than trying to come up with a way to derive a container name particular to the release, or chart, or chart release, this commit just hard-codes the name to something indicating the meaning of the value. This requires a compensating change to kubeyaml (which is include in quay.io/squaremo/kubeyaml:0.3.1). Additional: use type test rather than type assertion, so it will return `nil` rather than exploding.
squaremo
force-pushed
the
feature/985-support-fluxhelmrelease
branch
from
90a54f7 to
3f7b0bb
Compare
(built into kubeyaml 0.3.1, which is used in the most recent commit) |
|
👍 |
This adds support for treating FluxHelmRelease releases as workloads (i.e., things that refer to images and result in pods being created). They will appear in ListImages and ListServices API results, and can be updated and automated like other workloads.
Fixes #985.