-
Notifications
You must be signed in to change notification settings - Fork 25
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
helm: add helm chart for plugins installations #45
Conversation
ping @klihub @jukkar |
Another thing, would you like me to add
|
We'll need to fix that. It would be nice if the user could somehow configure/select (absolute helm n00b speaking here) whether to go with a stable/devel/unstable version. |
This would be nice to have as a separate PR.
This could be part of this PR.
Can you elaborate what does that mean ? |
Helm client has built in linting command to catch possible issues with charts and there is a github action that basically runs the lint command on github pull request. So, I was wondering, if we would need/want something like that. I don't have strong opinion here, because on one hand it is good to lint and catch possible bugs as early as possible (before merging and then realizing it) but on the other hand I don't expect to see many PRs against helm charts in the future. So, it doesn't really make sense to enable the GitHub action for every PR. GitHub action can be limited though to be executed only when charts directory is modified. So, I'm not sure to be honest. |
We need to update the documentation and add information about Helm after the docs pr #6 is merged. |
I have half cooked up PR for kustomize way of installing too. Will send once your PR is merged. |
22deea8
to
a5c0400
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thsnk @fmuyassarov. some quick comments below. Are you planning to submit documentation as a separate PR?
deployment/helm/nri-plugins/templates/noderesourcetopology.yaml
Outdated
Show resolved
Hide resolved
yes, but can add here as well. |
With this initial work, I'm fine with whatever you (or others think is preferred) |
a5c0400
to
7a9e784
Compare
@marquiz thanks for the reviews. Addressed comments. |
Added in #62 |
@fmuyassarov as I commented here I think we should have separate charts for the different policies and manage those as subcharts. When releasing the chart(s) in a helm repo we cannot rely on people relying on some policy-specific values file on their local machine. We need to have a chart that can be deployed with simple |
Yes, one way is to separate the plugins as stand alone charts instead of seperate values file. From the previous comment
I'm not sure I understand this. If a user installs based on the main values.yaml what is that user going to get as a result? I mean what plugin? I think it would be correct to actually have separate charts per plugin as you suggested above, although most of the things (templates) are going to be duplicated. But that will give is stand alone chart which has it is own lifecycle. |
Exactly (my comment was probably a bit cryptic). What I tried to say is that the chart can basically have only one values.yaml. You cannot choose between two different values.yaml in a chart when doing an install. With subcharts you shouldn't need to duplicate the templates, right? Have common values there plus all the templates. Then just override required stuff in the subchart. Wouldn't that work and eliminate most of the duplication? |
Unfortunately, I was unable to succeed or I chose not to proceed with the Library chart, and here's why: It has already become quite complicated, and I can't imagine how challenging it will be to maintain in the future. For instance, overriding the data part in the ConfigMap of the shared library alone requires at least three steps for a single parameterization.
As you can see, this involves simply overriding the configMap data portion from the Balloons Helm chart. We would need to do the same for all other fields that we want the user to be able to override, such as ports, protocols, image versions, and so on. However, what's even more problematic is that I'm currently unsure how users can perform these overrides. In the example above, the Balloons Helm chart is hard-coding the configMap data as "Hello World" within the file, and I don't know how to enable users to easily provide custom data from the terminal during chart installation. Essentially, the values.yaml file becomes useless in this kind of setup. Perhaps there is a way, but I have been unable to find it. As such, I don't want to complicate it further and instead have separate charts with their own templates, even if they result in duplication. Sorry for switching back and forth between different approaches. It's just that none of them seem to be perfect, or there is not an easy way to override common boilerplate as there is, for example, in Kustomize. If you're interested in seeing what this means in practice, you can take a look at my branch helm-monster branch, where I have kept changes for overriding comnfigMap and also DaemonSet if I recall it right. |
and sorry for delaying the release. I just really didn't want to have duplication .... |
62fc42d
to
4ec26e0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you @fmuyassarov and @marquiz consider this good enough to start with, then I'm also fine with it. I don't know enough about helm charts to be able to judge myself.
There are a couple of improvements I would like to see in Helm charts. Like those we discussed over the call today. But it doesn't have to be done here but instead as a follow up PR. So, I think this is fine to merge it, but I would like @marquiz to have his words, |
@marquiz ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments, mostly about naming
deployment/helm/resource-management-policies/balloons/Chart.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/templates/_helpers.tpl
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/templates/clusterrole.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/topology-aware/values.yaml
Outdated
Show resolved
Hide resolved
4ec26e0
to
7b01334
Compare
@marquiz comments are addressed now. |
deployment/helm/resource-management-policies/balloons/templates/clusterrole.yaml
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/templates/clusterrolebinding.yaml
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/templates/configmap.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/templates/configmap.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/topology-aware/values.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/values.yaml
Outdated
Show resolved
Hide resolved
|
||
metrics: | ||
port: 8891 | ||
protocol: TCP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that is relevant for the user to change? Drop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe not protocol and container port, but at least host port is relevant in case 8891 port on the host is utilized by something else already and the user wants to expose the metrics on the host
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed those fields and kept only the hostport, because I think that might be desirable by the user to be configured
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we want hostport? Then that port is reserved and e.g. another plugin cannot be deployed. Containerport should be enough, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, actually 😏 The HostPort setting could be THE way to achieve pod anti-affinity, if the daemonset controller takes that into account. I.e. one resource policy reserves that port and another one using the same port cannot be scheduled on that node. I don't like it necessarily but it could work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we want hostport? Then that port is reserved and e.g. another plugin cannot be deployed. Containerport should be enough, right?
each plugin can be exposed to a different hostPort. Why user might need is for exposing metrics fro example (Prometheus) to the host.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, actually smirk The HostPort setting could be THE way to achieve pod anti-affinity, if the daemonset controller takes that into account. I.e. one resource policy reserves that port and another one using the same port cannot be scheduled on that node. I don't like it necessarily but it could work
it might work, but when user has given some custom hostPort, then it will be missed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
each plugin can be exposed to a different hostPort. Why user might need is for exposing metrics fro example (Prometheus) to the host.
But isn't the usual way to have a K8s service to get the prometheus metrics? Not configure a hostport for each an every app you have? But let's leave it like this for now
deployment/helm/resource-management-policies/topology-aware/values.yaml
Outdated
Show resolved
Hide resolved
deployment/helm/resource-management-policies/balloons/values.yaml
Outdated
Show resolved
Hide resolved
0c11c94
to
5016b94
Compare
@marquiz thanks for another round of review. PTAL once more. Thanks |
FYI, just noticed that upstream documentation generation is broken. I get this error
Also #Manual ref is not found.
and TODO
and "terminal"
I suggest using "console" instead which works for me. |
deployment/helm/resource-management-policies/balloons/templates/configmap.yaml
Show resolved
Hide resolved
This commit adds a helm chart to install balloons and topology-aware NRI plugins. Signed-off-by: Feruzjon Muyassarov <[email protected]>
5016b94
to
c272c24
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @fmuyassarov for working on this 👍 I didn't spot anything obvious anymore so LGTM from my side.
Has anyone actually verified (i.e. tried in practice that they work) these?
I have not installed it but I tested generation of Manifests and since they are the same as we have in kustomize, or in e2e, I assume this should work too as long as other prerequisites are met. |
I could try this before we merge this, just a sec... |
Couple of notes:
|
Please rebase to main and tweak installation.md to add the helm location (in a separate commit). |
I have already added the documentation. We don't have a place to where we can upload the charts because we don't even have public images yet. Once we have images available and the initial release, then we can find a place for it in somewhere remotely from where it can be directly installed.
Yes, e2e changes will be on a follow up PR. |
Please see my comment above. |
This commit adds a helm chart to install balloons and topology-aware NRI plugins.
To install the chart into local k8s cluster without current default settings, simply running below is enough:
For testing and just only generating the final YAML without sending it to k8s
The images currently the Helm chart defaulting to are:
ghcr.io/containers/nri-plugins/nri-resource-policy-topology-aware:unstable
ghcr.io/containers/nri-plugins/nri-resource-policy-balloons:unstable