-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[idea] helm-operator event/hook system #4695
Comments
The issue #670 about supporting hybrid operators could be related to this idea. |
Great request! In fact, a redesign of the helm-operator's API is in flight that adds hook registration amongst other things. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Feature Request
Describe the problem you need a feature to resolve.
To maintain a helm-chart and an operator in parallel we would like to re-use as much as possible from our helm-chart.
Given that helm is limited in it's feature set the helm-operator can only support
Level II
operators.I started trying to re-invent the wheel to render the k8s objects based on our helm-chart and do everything the helm-operator does only to interact under specific circumstances differently, i.e. creating backups or recovering from an error.
Describe the solution you'd like.
I am looking for a way to create a Go controller which uses the helm-operator but gives me the ability to customize at specific lifecycle events.
A basic idea would be to create an event-system or callback functions which are executed at specific events like installation, reconciliation or deletion. This would give me the chance to look at the current state and decide how to proceed before helm applies any changes.
Further it would allow us to created
CRD
s which are independent from ourvalues.yaml
and overall more flexibility.I am curios what you are thinking about this approach.
Thanks in advance!
Best regards,
Simon
The text was updated successfully, but these errors were encountered: