Using Infrastructure as Code to install specific versions of Operators via OLM

[Abelenda Diego]

Hello,

I have a use-case where I want to validate a bunch of operator versions and
"release" a platform with these operators bundled using infrastructure-as-code.
But I found an issue that OLM does not seem to take this use-case into account.

I can't find a way to simply tell OLM to install a specific version of an
Operator with ArgoCD. From what I understand, when you want to install an
Operator with OLM you create a Subscription CR in a namespace. This
Subscription contains a field "installPlanApproval" that can be either "Manual"
or "Automatic".
In "Automatic" mode, the Operator will be updated immediately to the latest
version of the currently selected stream. So this is unusable for my use-case.
In "Manual" mode, the Subscription will trigger OLM to create a new
"InstallPlan" with a "random" name that needs to be modified to trigger the
installation of the Operator. This is does not map to how ArgoCD is intended to
work.

Currently I dropped the usage of OLM and use the helm charts of the Operators.
Which is kind of weird if I deploy the "platform" in OpenShift, some of the
Operators actually exist in an officially supported version installable through
OLM.
Is the use-case I have described something that OLM wants to cover?

Best regards,
Diego Abelenda

[Jeff McCormick]

https://olm.operatorframework.io/docs/tasks/install-operator-with-olm/#example-install-a-specific-version-of-an-operator

does the startingCSV work for your use case?

[Abelenda Diego]

Hello Jeff,

Thank you for your answer.

As I stated in my original message, I know this method exists, but my main issue
here is that this will not actually perform the installation of the Operator.
The process is as follows when using "installPlanApproval" set to "Manual":
* You create the Subscription with "installPlanApproval" set to "Manual"
* OLM will create a InstallPlan object with *a random name*
* you need to change the spec of the InstallPlan to modify the field approved
from false to true
* OLM will start installing the Operator

Having a random name here is a pretty big issue for ArgoCD. It will not wait
for the object to be created in the API and it will not be able to get the
object to modify only one field...

As I see it this workflow is made to be used:
* by humans and clicking into a UI (or editing the object using kubectl/oc)
* by other controllers that will be able to watch the creation of InstallPlans
and act on it


But ArgoCD is neither of these.

If I write here the craziest method I can think of:

* create a Subscription
* ignore the InstallPlan created by OLM
* create my own InstallPlan with only the "spec" no "status"

Something like:

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
name: install-rook-ceph-v1-5-7
namespace: rook-ceph
spec:
approval: Manual
approved: true
clusterServiceVersionNames:
- rook-ceph.v1.5.7

But my guess is that everything necessary for OLM to actually do something will
be missing... from the ownerReferences in the metadata, to the status.manifest
field... So I did not even try and asked here if the use-case was
even considered as valid.

Best regards,
Diego Abelenda

[Daniel Messer]

This is a limitation with the current API at the moment. I am looping in @operator-framework-olm-dev tean to add this to the list of concerns that we want to address with an improved API surface that is also more GitOps friendly. With the limited logic you can put into ArgoCD at the moment the only way to make this work is using automatic updates which will prohibit you from installing a particular patch version of the Operator.

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/20210308181156.30091422%40debian.

--

Daniel Messer

Product Manager Operator Framework & Quay

Red Hat OpenShift

[Shoubhik Bose]

I did consider creating a new InstallPlan in my Git repository with approved=true, the resource got ignored altogether :( 

spec:
  approval: Manual
  approved: true 
  clusterServiceVersionNames:

  - datagrid-operator.v8.1.0

- 

Shoubhik Bose

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAEQM%2BpMwwaLGK6efFy7hvZRF7VfWy9gpKrZnS8_pM%3DJSQES3Yg%40mail.gmail.com.

[Abelenda Diego]

Hello Daniel,

Thank you for your answer. That's what I thought when I looked at how the
InstallPlan was used by OLM. Let's hope that a new version of the API will
allow this kind of use-case. For now I will continue using the helm charts.

Best regards,
Diego Abelenda

On Mon, 8 Mar 2021 21:02:36 +0100
Daniel Messer <dme...@redhat.com> wrote:

> This is a limitation with the current API at the moment. I am looping in

> @operator-framework-olm-dev <operator-fram...@googlegroups.com> tean

[Abelenda Diego]

Hello Shoubhik,

That is exactly what I expected from a look at how OLM creates the InstallPlan
objects. They contain a lot of information that is not in the spec but in the
status field, the status.manifest field seems to be really important to get
work done.

Best regards,
Diego Abelenda

On Mon, 8 Mar 2021 17:11:37 -0500
Shoubhik Bose <shb...@redhat.com> wrote:

> I did consider creating a new InstallPlan in my Git repository with
> approved=true, the resource got ignored altogether :(
>
> spec:
> approval: Manual
> approved: true
> clusterServiceVersionNames:
> - datagrid-operator.v8.1.0
>
>
>
> -
> Shoubhik Bose
>
> On Mon, Mar 8, 2021 at 3:03 PM Daniel Messer <dme...@redhat.com> wrote:
>
> > This is a limitation with the current API at the moment. I am looping in

> > @operator-framework-olm-dev <operator-fram...@googlegroups.com>

> > <https://groups.google.com/d/msgid/operator-framework/CAEQM%2BpMwwaLGK6efFy7hvZRF7VfWy9gpKrZnS8_pM%3DJSQES3Yg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .
> >