Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Send helm-operator events to upstream #13

Closed
oliviabarrick opened this issue Sep 5, 2018 · 5 comments
Closed

Send helm-operator events to upstream #13

oliviabarrick opened this issue Sep 5, 2018 · 5 comments
Labels
blocked design Requires design before further action duplicate This issue or pull request already exists

Comments

@oliviabarrick
Copy link
Contributor

We currently send Flux events to Weave Cloud as events allowing upstreams to be aware of syncs, releases, and other events in Flux.

It would be great to be able to produce events from the helm-operator whenever it makes changes (or fails to make changes).

Are there any plans for sending events from the helm-operator upstream?

@squaremo
Copy link
Member

Yes, though not well-formed plans.

Briefly: the simplest thing would be to give the helm-operator an upstream URL, the same as for fluxd, and let it post its events there.

The helm operator already generates Kubernetes events though, and this would be doubling up .. So another more decoupled design is to use the Kubernetes event mechanism for fluxd too, and have a listener that posts both sets of events to the upstream.

@squaremo
Copy link
Member

squaremo commented Sep 27, 2018

The easy (first) option above would be fine as a start. I should note here that the helm operator currently generates Kubernetes events, but erroneously (it sends a success event whatever happens). An implementation either of the alternatives above would have to be more careful :-)

@sfrique
Copy link
Contributor

sfrique commented Dec 6, 2018

Any updates on this?
It would be nice to have it!

@stefanprodan stefanprodan transferred this issue from fluxcd/flux Aug 13, 2019
@stefanprodan stefanprodan added blocked design Requires design before further action duplicate This issue or pull request already exists labels Aug 13, 2019
@stefanprodan
Copy link
Member

Duplicate of #11

@kingdonb
Copy link
Member

kingdonb commented Sep 2, 2022

Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.

A new release of Helm Operator is out this week, 1.4.4.

We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.

Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.

In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.

Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.

We recommend upgrading to Flux v2 which is actively maintained ASAP.

I am going to go ahead and close every issue at once today,
Thanks for participating in Helm Operator and Flux! 💚 💙

@kingdonb kingdonb closed this as completed Sep 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocked design Requires design before further action duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

5 participants