-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add support for multi-path to the Helm Operator #1348
Comments
Technically there's no reason to provide a path to the helm operator at all -- each FluxHelmRelease should just give the full path from the top of the repo. |
Having said that, I am curious about the use case suggested in your example. Do you want to reuse the same FluxHelmRelease resources in different places, with the helm operator pointing at distinct directories containing charts that have the same name but otherwise differ? |
I'm interested in this too for reasons similar to @kozejonaz Can you give an example of this
Not sure what |
I mean there's no especial reason to supply There is the one reason -- and now I read through again, I see that's what @kozejonaz what's getting at. It does seem rather counter to the point of charts, which is to have a single template to which you refer in many places. I can see how referring to a chart in a git repo means you can only run one version of it, and perhaps that's where the motivation arises for having charts in more than one place. |
@squaremo Sorry for the late reply! Before I created this I was under the impression that the Helm operator would need to be able to read several chart paths to be able to use several Helm operators against the same branch. After some discussion in Slack (start at https://weave-community.slack.com/archives/C4U5ATZ9S/p1536325875000100 and read on) @geoah pointed out that I could achieve what I wanted by having one location for Helm charts. This is achieved by pointing all Helm operators to the single charts path using I can't think of many good reasons to do this anymore, except for consolidating how the daemon and the Helm operator uses the paths maybe? If you wanted to use several versions of a chart, I guess you could add both versions as separate charts as well. You could sub-chart them to avoid too much copy+paste. But maybe this is a potential argument for doing this. I should have been a bit more descriptive when I logged this. |
@kozejonaz Thanks for this update, it is really helpful. |
As some background info, I am experimenting with the structure of the charts folder. Rather than drop all the charts in a flat structure in the At the moment, I'm trying to move from a flat charts structure to one with nomenclature which will make it easier to know what's what... It's a WIP. Before:
After:
This pretty much answers my original question about So for the same reason then, I do not need this feature either, I can specify it in the CRD. So to give an example in code, I am presuming the following is the correct way to achieve what I want to try: helm install \
--name flux \
--namespace kube-system-addons \
--set rbac.create=true \
--set helmOperator.create=true \
--set helmOperator.git.chartsPath=addons/charts \
weaveworks/flux apiVersion: helm.integrations.flux.weave.works/v1alpha2
kind: FluxHelmRelease
metadata:
name: kubernetes-dashboard
namespace: kube-system-addons
labels:
chart: kubernetes-dashboard
spec:
chartGitPath: kube-system-addons/kubernetes-dashboard
releaseName: kubernetes-dashboard So changing |
@stephenmoloney That is exactly right :) |
@kozejonaz @stephenmoloney It sounds like both of you can get by without this feature -- shall we close it? |
@squaremo That is perfectly fine by me. |
@squaremo yes, can close this. I have a working solution as per #1348 (comment) |
Thanks both! |
Now that you have multi-path support for Flux through
--git-path
, it would be great to have the same for the Helm Operator through thehelmOperator.git.chartsPath
argument so that you could have Helm Operator 1 looking at something likecharts/common
andcharts/cluster1
, and Helm Operator 2 looking at something likecharts/common
andcharts/cluster2
.The text was updated successfully, but these errors were encountered: