Operatorhub seems not updated anymore

[Elyytscha]

Preflight Checklist

• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
• [X] I agree to follow the Code of Conduct.

Problem Description

https://operatorhub.io/operator/vault is really old i noticed, could you please update this again?

Proposed Solution

make pr's at the operatorhub repo for new vault operator versions

Alternatives Considered

No response

Additional Information

No response

[akijakya]

Hi @Elyytscha, I am going to raise this on the next sync with the maintainers but there are some uncertainties around the operator and it is not guaranteed we will continue with updating it on OperatorHub.io.

[Elyytscha]

well as we are lazy devs, we like operatorhub and the idea that we can update our installed software due to this mostly automated without even touching (installPlanApproval: Automatic) sometime something breaks, but we are aware of the fact that every operator is basically a different opensource project and we have to decide per project(=operator) basis if its worth to run automatic upgrades or not, but ~95% of our operators are on automatic upgrade without issues. basically our prometheuses, alertmanagers, grafanas, argocds, tekton, etc are upgrading automated due to operatorhub and operators.

would be cool if we could do this too for our vault again :)

also its a really good opportunity to have a place where your operator is bundled with an explicit version of hashicorp vault against the operator was tested, often a new release on operatorhub for an operator just means the operator was tested and verifed (and released&published) with a new version of the software the operator operates.

[ramizpolic]

I am not sure how safe it is to have BV on automated upgrade as breaking changes could reflect on the whole stack usability. We could probably add it to operatorhub without issues, but I would really like to avoid this. This often creates a lot of issues due to lack of transparency between upgrades which creates a lot of problems for us as well in terms of debugging and answering issues that are mostly related to upgrades (we are lazy too so I feel you :smile:). I'm sure it has its benefits, but I would advise doing manual upgrades of BV either way.

[Elyytscha]

which is not a problem with olm or operatorhub because you can do always:

If an installed Operator has the approval strategy in its subscription set to Manual, when new updates are released in its current update channel, the update must be manually approved before installation can begin.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-operator
  namespace: operators
spec:
  channel: stable
  name: my-operator
  source: my-catalog
  sourceNamespace: operators
  installPlanApproval: Manual

or you can just hardcode the vault version in the vault cr.

but as I expierienced, its way more safe to auto update operators and DONT hardcode the version for the application in the CR itself, because as said, mostly an operator upgrade means the operator is ready for a new version of the app it operators, which mean the old version of the app hardcoded in the cr could be incomaptible with the new operator version, those issues i saw already arise.

just to note, teams which are managing 100+ kubernetes clusters have to rely on automatic upgrades, the can't uprgade 100+ clusters per hand or any of the cluster systems itslef, this has to be done automatically and errors arising through this have to be sent via acurate notification channels (example pagerduty[automated email,slack,sms,phone-call based on severity])

what to add is, that this is a state which BV does not want imo because the actual state is, any openshift cluster in the world, which utilizes olm and operatorhub per default, will install a really old version of the bv vault operator, which could result in potential reputation damage for BV itself.

also generally to say is olm has way more advanced capabilites then helm for installing and managing operators, feels way more manageable then helm charts, feels way more enterprise ready

[larsks]

I am not sure how safe it is to have BV on automated upgrade as breaking changes could reflect on the whole stack usability

If the operator declares versions and channels properly, you can simply pin your operator subscription to the current minor release (e.g., channel: stable-1.21) and avoid breaking changes as long as the bank-vault developers follow standard versioning practices.

[DrummyFloyd]

any news regarding this https://operatorhub.io/operator/vault

it's stuck to 0.4.10

any will to update ?

[Elyytscha]

As far as I have understood there is no will to update:

We could probably add it to operatorhub without issues, but I would really like to avoid this.

Just to note: olm solves things which helm does not (managing the correct crd versions on the cluster for the operator)

[ramizpolic]

As far as I have understood there is no will to update:

We could probably add it to operatorhub without issues, but I would really like to avoid this.

Just to note: olm solves things which helm does not (managing the correct crd versions on the cluster for the operator)

We are revisiting this and will re-release the operator under OperatorHub. We have a bit of work at hand and would like to finish up the work we started on new Bank-Vaults projects before addressing this.

[Elyytscha]

I would like to help with this in my spare time, I just didn't feel convinced to contribute something, which isn't wanted by the maintainers :)

I can recommend to look at this, it can serve as reference | howto, this could be done basically the exact same way https://argocd-operator.readthedocs.io/en/latest/developer-guide/development/ https://github.com/argoproj-labs/argocd-operator/blob/master/Makefile

[Elyytscha]

just wanted to let you know that i'm already at a state which basically works, just need some spare time to look into the issues which i'm seeing right now