Skip to content

Dependency on OLM & Operator SDK #14

Description

@liafizan

Hello! Thank you for this writing & maintaining this operator.

Could we as a user of the operator bypass dependency on Operator-SDK & OLM? These tools are great and allow us to install/deploy our operator easily. However, as an end user I would like to use either

  • Helm
  • Kustomize
  • Kubectl
    to deploy the operator. Installing OLM which in turn installs additional CRDs/Service accounts etc is just exposing my cluster to a big threat radius. Plus it also puts onus on me to manage/maintain OLM which at present, we do not want to uptake.

Looking at the docs, I should have been able to use kustomize ( makefile ) & in fact I did try to install the operator using Kustomize bypassing the above as shown below

> make install # CRDs installed

> make deploy IMG=iad.ocir.io/oracle/oci-service-operator-bundle:1.1.0

However, I see this issues:

# Error when make deploy 
unable to recognize "STDIN": no matches for kind "Certificate" in version "cert-manager.io/v1"
unable to recognize "STDIN": no matches for kind "Issuer" in version "cert-manager.io/v1"
make: *** [deploy] Error 1

Assuming there is some dependency on some sort of certmanager but I cannot find that in Makefile. Trying to debug this further

Also, when deploying via OLM, the operator gets deployed in default namespace but when using kustomize, it creates a namespace oci-service-operator-system. Perhaps OLM should also default to this behavior.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions