Publish envoy-operator charm to `metadata-envoy` instead of `envoy`
orfeas-k opened this issue · comments
Context
This charm is for KFP's metadata-envoy component and not a general envoy component. During the update for CKF 1.8 release, we changed from using image envoyproxy/envoy:v1.12.2 to gcr.io/ml-pipeline/metadata-envoy:2.0.2. This made sense, since the charm is not a really configurable general envoy charm but rather configures envoy in order to imitate the kfp's metadata-envoy functionality.
At the same time, there are two charms in charmhub:
Proposal
We should archive envoy charm in Charmhub and start publishing under metadata-envoy. This way, we 'll avoid confusion and also make explicit that this is not a generalized envoy charm.
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5214.
This message was autogenerated
We discussed about this but have not yet decided if we will implement this. We still think that envoy name is super misleading, as that is a component on its own. However, renaming it to metadata-envoy will result in more steps for 1.8 -> 1.9 upgrade. If we propose a solid upgrade story, we could make the change. Kind reminder to CKF 1.9 release lead @ca-scribner to keep that in mind.
@orfeas-k this is a bit confusing to me
In the Kubeflow bundle I see envoy https://github.com/canonical/bundle-kubeflow/blob/main/releases/1.8/stable/kubeflow/bundle.yaml#L27
So, is that charm A or B?
A. envoy by envoy charmers
B. metadata-envoy by Kubeflow charmers
Hi @gustavosr98, the one the bundle inclues is envoy by envoy charmers. You can be sure about it by looking at the line exactly you sent since this is the name of the charm that the bundle tries to pull from charmhub. It would have to say metadata-envoy in order to be option B.
That being said, the confusion you got into is exactly the type of confusion the current charm names introduce and that we would like to get rid off by renaming the charm for release 1.9.