-
Notifications
You must be signed in to change notification settings - Fork 637
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
Add Helm functionality #799
Conversation
I forgot, this is how the usage looks: ❯ VERSION=0.17.1 make helm-chart
== KUSTOMIZE (image and namespace) ==
cd config/manager && /home/mark/src/github.com/mamercad/awx-operator/bin/kustomize edit set image controller=quay.io/ansible/awx-operator:0.17.1
cd config/default && /home/mark/src/github.com/mamercad/awx-operator/bin/kustomize edit set namespace awx
== HELM ==
cd charts && \
/home/mark/src/github.com/mamercad/awx-operator/bin/helm create awx-operator --starter /home/mark/src/github.com/mamercad/awx-operator/.helm/starter ;\
sed -i -e 's/version: 0.1.0/version: 0.17.1/' awx-operator/Chart.yaml ;\
sed -i -e 's/appVersion: 0.1.0/appVersion: "0.17.1"/' awx-operator/Chart.yaml ;\
sed -i -e 's/description: A Helm chart for Kubernetes/description: A Helm chart for the AWX Operator/' awx-operator/Chart.yaml
Creating awx-operator
apiVersion: v2
appVersion: "0.17.1"
description: A Helm chart for the AWX Operator
name: awx-operator
type: application
version: 0.17.1
== KUSTOMIZE (annotation) ==
cd config/manager && /home/mark/src/github.com/mamercad/awx-operator/bin/kustomize edit set annotation helm.sh/chart:awx-operator-0.17.1
cd config/default && /home/mark/src/github.com/mamercad/awx-operator/bin/kustomize edit set annotation helm.sh/chart:awx-operator-0.17.1
== SLICE ==
/home/mark/src/github.com/mamercad/awx-operator/bin/kustomize build config/default | \
/home/mark/src/github.com/mamercad/awx-operator/bin/kubectl-slice --input-file=- \
--output-dir=charts/awx-operator/templates \
--sort-by-kind
Wrote charts/awx-operator/templates/namespace-awx.yaml -- 156 bytes.
Wrote charts/awx-operator/templates/serviceaccount-awx-operator-controller-manager.yaml -- 158 bytes.
Wrote charts/awx-operator/templates/configmap-awx-operator-awx-manager-config.yaml -- 472 bytes.
Wrote charts/awx-operator/templates/customresourcedefinition-awxbackups.awx.ansible.com.yaml -- 2685 bytes.
Wrote charts/awx-operator/templates/customresourcedefinition-awxrestores.awx.ansible.com.yaml -- 2740 bytes.
Wrote charts/awx-operator/templates/customresourcedefinition-awxs.awx.ansible.com.yaml -- 18122 bytes.
Wrote charts/awx-operator/templates/clusterrole-awx-operator-metrics-reader.yaml -- 216 bytes.
Wrote charts/awx-operator/templates/clusterrole-awx-operator-proxy-role.yaml -- 348 bytes.
Wrote charts/awx-operator/templates/clusterrolebinding-awx-operator-proxy-rolebinding.yaml -- 359 bytes.
Wrote charts/awx-operator/templates/role-awx-operator-awx-manager-role.yaml -- 1495 bytes.
Wrote charts/awx-operator/templates/role-awx-operator-leader-election-role.yaml -- 524 bytes.
Wrote charts/awx-operator/templates/rolebinding-awx-operator-awx-manager-rolebinding.yaml -- 374 bytes.
Wrote charts/awx-operator/templates/rolebinding-awx-operator-leader-election-rolebinding.yaml -- 382 bytes.
Wrote charts/awx-operator/templates/service-awx-operator-controller-manager-metrics-service.yaml -- 351 bytes.
Wrote charts/awx-operator/templates/deployment-awx-operator-controller-manager.yaml -- 1823 bytes. |
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.
We'd really use this chart! Thanks for kickstarting this
No worries; Helm's my preferred way right now (so, I need it, heh). Also, you'll need to push a |
Yeah, we use Helm all over, so I need this as well. Hopefully the community accepts this. |
Let me update the |
I'll add "install using Helm" to the |
Hello. Thank you for taking the time to write and submit this PR. Right now I have some concerns that would need to be addressed before we would be able to consider merging this code. We've put in a great deal of effort to remove any hardcoded versions or rendered files in the repo, enabling us to do releases at any time by running a simple workflow. We have a relatively small team and do not have the resources to constantly update files when we do a release. As you can see in the Makefile, we pull the version from git: Line 6 in c02e059
And all of the resources are generated dynamically by kustomize: Line 89 in c02e059
Similarly to what I said in #657, maybe we could generate these files at release time. |
Sure, I can work on that. |
@shanemcd I think this is closer to what you're looking for, please have another look when you have some time. |
Using my fork; after pushing ❯ helm search repo awx-operator
NAME CHART VERSION APP VERSION DESCRIPTION
awx-operator/awx-operator 0.17.3 0.17.3 A Helm chart for the AWX Operator |
Thanks for this! I've tried to install it but saw the following
Web search indicates that this error is quite generic and hence I am not sure if it really relates to the helm chart. Wanted to post it anyway... |
Seems like you might have either AWX or the AWX Operator already deployed? I just tried this again, here's a gist. |
This is looking pretty great @mamercad. Thank you for all your work here. Apologies for being slow to respond, we've been been busy lately. I want to test this out, but I'm on vacation most of next week so it might be the week of the 14th before I can give this a proper review. |
No worries at all; thanks for taking a look -- I'm in no rush on this whatsoever, I can always use my fork if needed -- have a nice vacation! |
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.
Amazing work on this. I left some minor comments just after cloning and reading the code. I haven't yet tried it out on my fork. Will do that sometime next week. Thanks again, this is a great contribution.
No worries; appreciate the review! |
@mamercad I just sat down to finally test this and noticed I just merged a PR that created a merge conflict. Would you mind resolving that? Or I can handle it and push to your branch. Let me know what you prefer. |
I can rebase, give me a bit. |
I'm also seeing this:
It looks like this is because on my machine |
Yep, it's using chart releaser, which operates on a branch. It's been a while since I've looked at this as well at this point, but, I think it's better to use a separate branch for GitHub Pages (versus the default branch of the project), and that by default, is a branch named |
Looking into it now, not sure I'll figure it out before I get pulled off to something else. After reading a bit it looks like it's expecting a clean slate with a "charts" directory. I'm going to try that first. |
Hope you dont mind me pushing to this branch. Found a small little problem in your Makefile changes. We probably didn't see it in GHA since their runners already have yq installed. |
Not at all :) -- we'll (re)figure out how this works, together, hehe. |
We are really looking forward to an official helm chart to use. Can I conclude that you guys are close to a helm chart installation method for the operator? |
@mamercad By the way, I am looking in to code, the values.yaml is empty. no one can adjust values. I think this is just wrapper, and I think whole helm chart code should exist in codebase. In your code, chart tgz file is generated only. not easy to see diff. |
We can't do this because operator-sdk (and surrounding tooling like OLM) is built on top of an auto-generated kustomize-based framework. And from what I can tell it seems to be more flexible than helm.
This is a pretty fair complaint. I dont know much about helm, but do these values require you to use helm's templating language? |
Without this I was seeing: $ make yq tar: yq_linux_amd64: Not found in archive tar: Exiting with failure status due to previous errors make: *** [Makefile:240: yq] Error 2
This was mostly me working around a limitation in chart-releaser where it does not allow for uploading a chart to an existing release.
@mamercad I rebased and resolved a conflict with this PR + pushed 2 new commits that:
The comment from @Hokwang is valid and makes me question the overall usefulness of this, but I guess it's better than nothing and will work for the general case. We can continue to iterate on it if there are good solutions to these problems. |
Totally agree; it's just a start and a framework. If folks find it useful going forward, we can put work towards the Helm values. |
So right now there is no option to modify values for the helm chart? You just have to take what the chart deploys, right? Or is there a workaround for now when the upstream values.yaml file is still empty? |
This was just merged; so no, there's no workaround right now. As it stands right now, it packages up the existing deployment method, i.e., |
@mamercad Thanks for contributing this in Quick question, could you provide some steps to safely migrate from the kustomize deployment to helm without losing the existing instances? Would be nice if this could be added to the upgrade section of the project's readme. |
Unfortunately, I can't give advice on this other than "caveat emptor". If it were me, I'd definitely test this in a sandbox before production. If I can get some time, I'll try this in my homelab (but, to be honest, I've been swamped with work lately). |
No rush, I'll try to deploy it when I gain more 'confidence' - I think I'll just remove all resources except the crds and redeploy via helm (which should take ownership of the CRDs then) |
Yeah, that sounds reasonable. Not sure how closely you looked -- the Helm chart is simply packaging up the result of |
Might help with #657; you can see how this works in my fork if you like:
The deployment isn't up-to-date because there's no
awx-operator:0.17.1
pushed up to quay right now.