Open raballew opened 2 years ago
Hi @raballew,
At this point, there is not much that we are changing in the existing set of APIs such as a Subscription. The use case is perfectly valid, and we would like to address this type of flexibility (configure properties at runtime) in the new set of APIs.
As a workaround, I believe embedding the annotations directly on the CSV should see them propagated downwards towards the deployment. Does that work for your use case?
Hi @exdx,
annotations on the CSV are propagated and this process works just fine. The initial problem unfortunately remains if I would like to use this as part of a GitOps workflow.
I searched in this repository but could not find any drafts or proposals with regards to the new set of APIs. Could you point me in the right direction?
Hi @raballew, we have been iterating on our new APIs here: https://github.com/operator-framework/rukpak. It's still very early days, but there are some docs and examples to follow
Feature Request
Is your feature request related to a problem? Please describe. I am developing an operator that needs to access information hosted in a second network. Hence I would like to use Multus to deploy a multi-homed operator pod but it seems that this not possible at install time. This is due to the matter of fact, that annotations can not be passed to the deployment as part of the SubscriptionSpec. Only patching the CSV after the installation seems to work at the moment which is somewhat imcompatible with GitOps workflows.
Describe the solution you'd like Passing annotations to the operator pod can be done in different ways. Anyway my prefered solution is similar to [1] but instead of using
PodSpec
for.spec.config
I would suggest using aPodTemplateSpec
[2].[1] https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/contributors/design-proposals/operator-config.md [2] https://github.com/kubernetes/api/blob/b8c40e080bc5e830097df540d4ef804034cb5bdb/core/v1/types.go#L3907