Recommended pattern for bundling a plugin into an Operator
RyanMillerC opened this issue · 11 comments
Is there a recommended pattern to bundle a dynamic console plugin into a Go-based operator?
We don't have an example for this today, although it's something we should look at adding since operators are a common way to deliver plugins.
If your operator already creates a service on the cluster, it's possible to use http.FileServer to serve the static plugin assets. Otherwise, you could add a sidecar container using any HTTP server like nginx or caddy. If your operator adds an console.openshift.io/plugins annotation to its CSV, console will prompt to enable the plugin on operator install. There's an example of the annotation in the enhancement here: https://github.com/openshift/enhancements/blob/master/enhancements/console/dynamic-plugins.md#delivering-plugins
Hope this helps.
Thanks @spadgett, this helps! I'm close but not 100% there yet. If I can get it working I will gladly contribute an example using an Operator. 😃
I went the Nginx route and have generated a container image for my console plugin. In my operator's ./config/manifests/bases/ directory I've included a Deployment (using the nginx image), Service, and ConsolePlugin. When I run make bundle, only the Deployment and Service are generated under ./bundle/manifests.
If I deploy the bundle (without ConsolePlugin), manually add the ConsolePlugin, and enable it, everything works great! I need to figure out why make bundle isn't including that manifest... This could be simply my lack of knowledge around the Operator SDK.
Another question I have is around namespaces. At the moment I have hardcoded the namespace in my ConsolePlugin. If someone installs the operator into a different namespace, the ConsolePlugin won't match. Is there a way around that?
# Example spec from my ConsolePlugin
spec:
service:
name: cat-facts-console-plugin
namespace: cat-facts-operatorThe code needs cleaned up but I managed to get something working: console.go. Instead of supplying manifests through the OLM bundle, I'm creating the Deployment, Service, and ConsolePlugin in my controller's Go code. I'm calling that code in main.go before starting the reconcile loop on my controller. Not 100% if that is the best place to do it but it does work.
Two improvements I need to make:
- I still have the namespace hard-coded. It shouldn't be hard to determine the namespace the controller is running and use it.
- I'm not checking to validate that the cluster actually has a ConsolePlugin CR available. Right now my operator will error on non-OpenShift Kubernetes clusters and on earlier versions of OpenShift.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
/remove-lifecycle stale
I'd like to add a reference link to my example operator from this repo's README. I should probably get my repo moved out from under my GitHub user first though. I'm thinking of moving it under redhat-cop, unless you have a better place for example OpenShift related code. https://github.com/RyanMillerC/cat-facts-operator
Another repo that could be linked for reference is https://github.com/kiali/openshift-servicemesh-plugin. That is an Ansible-based operator that includes a console dynamic plugin.
@RyanMillerC Oh nice! Yes, this was definitely needed. I think we can link out to your personal GitHub repo for now and then update the link if we can move it somewhere better, maybe the openshift org? Have you talked to the OLM team about making it a sample?
As an aside, we've discussed creating a hello world operator for OpenShift console CI tests... We might consider using this instead, and it would let us test enabling plugins during operator install flows. @jhadvig @jcaianirh FYI
@alimobrem FYI
I was told redhat-cop is not a good place for example code. I'm open to moving the repo wherever makes the most sense. It would be awesome if I could still be a repo owner in the new location. I'm working on implementing a console plugin for the patterns operator. There's some things I'm doing there that I would like to copy over to cat facts when I have time.
In the meantime I will open a PR to add links for both my example and the service mesh plugin.
I haven't talked to the OLM team but I'm open to talking with them. Do you have a point of contact on their team?
Thanks! 😃
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen.
Mark the issue as fresh by commenting/remove-lifecycle rotten.
Exclude this issue from closing again by commenting/lifecycle frozen./close
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.