Operator SDK 1.0 Admission Webhooks

[Michael Greenberg]

The Operator SDK v1.0 documentation includes a section titled Admission Webhooks.

Following the steps listed (and some that aren't):

mkdir test-operator
cd test-operator
go mod init example.com/m/v2
operator-sdk init --project-version=2 --domain example.com
operator-sdk create webhook --group cache --version v1alpha1 --kind Memcached --defaulting --programmatic-validation
make manifests
make run

Results in:

go vet ./...
# example.com/m/v2/api/v1alpha1
api/v1alpha1/memcached_webhook.go:29:10: undefined: Memcached
api/v1alpha1/memcached_webhook.go:39:28: undefined: Memcached
api/v1alpha1/memcached_webhook.go:42:10: undefined: Memcached
api/v1alpha1/memcached_webhook.go:51:28: undefined: Memcached
api/v1alpha1/memcached_webhook.go:54:10: undefined: Memcached
api/v1alpha1/memcached_webhook.go:62:10: undefined: Memcached
api/v1alpha1/memcached_webhook.go:70:10: undefined: Memcached
make: *** [Makefile:51: vet] Error 2

The "Memcached" structure is created automatically in the Operator Scope example.

The Admission Webhook section was not included in the https://master.sdk.operatorframework.io/docs/building-operators/golang pages.

Is there a documented example of how to create a Go based Admission Webhook using the Operator SDK version 1.0 or newer?

Thanks,
Michael

[Matt Dorn]

Hi Michael,

This content from kubebuilder's doc page should be applicable and gives you a feel for the webhook authoring workflow: https://book.kubebuilder.io/multiversion-tutorial/webhooks.html?highlight=create,webhook#webhook-setup

I will let someone from the operator-sdk team chime in on any existing op-sdk webhook documentation.

Matt

--
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/a572eccb-b2b3-e79d-470f-ceab3085f696%40redhat.com.

[Eric Stroczynski]

Thanks Matt, that's the correct doc, and SDK docs link to it. Make sure you're following the kustomize configuration steps (specifically the section about uncommenting kustomization.yaml lines) before you run `make deploy`.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAD_SvZQVtq9mtZ3u%2Bv_Efz6abXY6xNDYqh%2Bid%2BJZ96wvuZSpbA%40mail.gmail.com.

--

Eric Stroczynski

Senior Software Engineer
Operator SDK Team
Red Hat Inc. San Francisco Office

[huizen...@gmail.com]

I have been trying to use the webhook support baked into OLM as well as using sdk 1.0.1, it would be great if there were also a documented example that deployed via OLM. I have seen this link https://access.redhat.com/documentation/en-us/openshift_container_platform/4.5/html/operators/olm-webhooks
Which mentions 

• The TLS certificate file is mounted to the Deployment at /apiserver.local.config/certificates/apiserver.crt.
• The TLS key file is mounted to the Deployment at /apiserver.local.config/certificates/apiserver.key
  

But I have not been able to get olm to create the mutating or validating webhook config resources, the install status continually flips between "installing","installReady" and "pending"  I see a status reason message flash by saying "message: calculated deployment install is bad"  but nothing else.

I thought that maybe this support only worked for a clusterscoped install so tried that but still see same error 

[vnar...@redhat.com]

Hi,

This error may occur in two cases:

1. When the admission/mutating webhook config present in the CSV is missing some field or has an invalid value specified. In that case, looking at the installplan may help us to find errors. Here is an example CSV with the right validation/mutating config: CSV. 

2. In case of conversion webhook, when the TLS certificate/key is not present at the location where controller-runtime expects it to be. In that case, you may have to pass the server config while creating  webhook server.

Since you are facing this error while using mutating/validating webhooks, I suspect it to be because of something being wrong in webhook config present in CSV. 

`kubectl get installplan XXX -n XXX -o yaml` would help us to identify the resource which is possibly causing the error.

This is an example of a working memcached-operator with webhooks enabled.

Hope this helps. Please let us know if you are still facing errors.

Thanks,

Varsha Prasad

Software Engineer
Operator SDK Team
Red Hat Inc. San Francisco

[Michael Greenberg]

Eric, Matt,

Thank you for the prompt responses. The point about the kustomize configuration steps was very helpful.

That being said, the tips did not resolve the issue that I was seeing during the build:

api/v1alpha1/memcached_webhook.go:29:10: undefined: Memcached

After further investigation, it appears that the issue may be in the documentation. The Quickstart section states:

Create a simple Memcached API:
operator-sdk create api --group cache --version v1 --kind Memcached --resource=true --controller=true

whereas the Admission Webhooks section states:

To add a webhook to your Operator SDK project, first you must scaffold out the webhooks with the following command.
$ operator-sdk create webhook --group cache --version v1alpha1 --kind Memcached --defaulting --programmatic-validation

This resulted in Go languages files being created in different directories (api/v1, api/v1alpha1).

After changing the webhook scaffold creation command to:

$ operator-sdk create webhook --group cache --version v1 --kind Memcached --defaulting --programmatic-validation

The application built as expected.

Should a bug be filed on the documentation? Where?

Regards,
Michael

[Eric Stroczynski]

You can file a bug in the operator-sdk repo or make a pull request against the v1.0.x branch for that change to the webhook doc. We've already removed that doc in master and point to the kubebuilder webhook doc instead, so the v1.1.0 docs will accurately describe an example webhook implementation.

[Juraci Paixão Kröhling]

On 30.09.20 19:57, Eric Stroczynski wrote:
> You can file a bug in the operator-sdk repo

> <https://github.com/operator-framework/operator-sdk/> or make a pull

> request against the v1.0.x branch for that change to the webhook doc

> <https://github.com/operator-framework/operator-sdk/blob/v1.0.x/website/content/en/docs/building-operators/golang/webhooks.md>.

> We've already removed that doc in master and point to the kubebuilder
> webhook doc instead, so the v1.1.0 docs will accurately describe an
> example webhook implementation.

We might still need some documentation touching the OLM side of things.
My operator (opentelemetry-operator) works fine in Kubernetes, including
the webhooks, but I'm not sure if the same generated manifests would be
suitable to use with OLM. For instance, the CRD that is part of the
generated bundle includes a snippet like this:

```
spec:
conversion:
strategy: Webhook
webhookClientConfig:
caBundle: Cg==
service:
name: app-operator-webhook-service
namespace: app-operator-system
path: /convert
```

Note how the namespace is an actual value, and not a placeholder. Is it
going to be replaced, and if so, when and by which component?

One thing could be clearer as well: is the cert-manager available in
OpenShift by default? Or do I need to account for the differences
between OpenShift and Kubernetes in terms of provisioning the certs? And
finally, I'm currently debugging a problem when deploying the operator
via OLM where the CSV is invalid (null value for
admissionReviewVersions). At this point, I'm not sure if it's a problem
with the sources that generate my bundle, or a bug in the Operator SDK,
or OpenShift itself. Having a reference, end-to-end example that works
with OLM would have been valuable to me.

- Juca.

[Alexander Greene]

Hello Juraci,

Thanks for using OLM. Please review OLM's existing documentation detailing OLM's support for admission and conversion webhooks. Some quick notes based on your questions:

- OLM will make sure that the webhook resources are created with the correct namespaces

- OLM will inject the CA (likely in the wrong place, but OLM plans to give you a way to configure the mount point)

- I'll need to look into the null value for `admissionReviewVersions`, could you create an issue against OLM?

I have an example webhook managed by OLM that implements a validating, mutating, and conversion webhook here that you can reference.

I hope this helps!

Best,

Alex

Alexander W. Greene Software Developer +1 412 508 5479 greene...@gmail.com

--
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/fbfd64bd-90f7-4bc9-f7e7-b6047d9b54a3%40redhat.com.

[Juraci Paixão Kröhling]

On 01.10.20 16:07, Alexander Greene wrote:
> Thanks for using OLM. Please review OLM's existing documentation

> <https://olm.operatorframework.io/docs/advanced-tasks/adding-admission-and-conversion-webhooks/>

That's pure gold, don't know how I could have missed it, thanks!

> - I'll need to look into the null value for `admissionReviewVersions`,
> could you create an issue against OLM

> <https://github.com/operator-framework/operator-lifecycle-manager/issues>?
>

Let me read the docs and compare with your code, perhaps this is
something on my side.

> I have an *example webhook managed by OLM that implements a validating,
> mutating, and conversion webhook* here
> <https://github.com/awgreene/webhook-operator/tree/olm> that you can

> reference.
>
> I hope this helps!

I think it does, I'll try it out right now.

Thanks,
Juca.

[Juraci Paixão Kröhling]

> I think it does, I'll try it out right now.

I just opened a PR against your repo with the results of running `make
bundle` with my current tooling. The `null` for
`admissionReviewVersions` is appearing there, which makes me believe we
are using different tool versions?

https://github.com/awgreene/webhook-operator/pull/1

- Juca.

[Juraci Paixão Kröhling]

Is anyone able to take a look at this one? I don't really know how to
move forward and need some assistance.

- Juca.

[Alex Greene]

Hello Juraci - I responded to your comments on the draft PR.

--
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/85ca203f-cfc5-34fa-098c-1a680ac145ca%40redhat.com.

--

Alexander Greene
He - Him - His

Software Developer

C: 412-508-5479

IRC: agreene

[Juraci Paixão Kröhling]

Sorry for returning to this topic, but I just had the chance of trying
v1.1.0 with the fixes to the problems I was experiencing with v1.0.0.

I'm happy to report that I could get past those issues, but I've now
bumped into something new: when I try to install the operator via OLM,
the deployment is created but pods can't be created. I can see the
following events (kubectl get events), which are shown repeatedly:

```
0s Normal SuccessfulCreate
replicaset/webhook-operator-controller-manager-7db86bf785
Created pod: webhook-operator-controller-manager-7db86bf785-tmnth
0s Normal Scheduled
pod/webhook-operator-controller-manager-7db86bf785-tmnth
Successfully assigned
openshift-operators/webhook-operator-controller-manager-7db86bf785-tmnth
to crc-j55b9-master-0
0s Warning FailedMount
pod/webhook-operator-controller-manager-7db86bf785-tmnth
MountVolume.SetUp failed for volume "cert" : secret
"webhook-server-cert" not found
0s Warning FailedMount
pod/webhook-operator-controller-manager-7d45489ff9-jtwzz
MountVolume.SetUp failed for volume "cert" : secret
"webhook-server-cert" not found
0s Warning FailedMount
pod/webhook-operator-controller-manager-7db86bf785-tmnth
MountVolume.SetUp failed for volume "cert" : secret
"webhook-server-cert" not found
0s Warning FailedMount
pod/webhook-operator-controller-manager-7674bc995-82vg7
MountVolume.SetUp failed for volume "cert" : secret
"webhook-server-cert" not found
0s Warning FailedMount
pod/webhook-operator-controller-manager-7f6df97fd7-ht8qm
MountVolume.SetUp failed for volume "cert" : secret
"webhook-server-cert" not found
0s Normal SuccessfulDelete
replicaset/webhook-operator-controller-manager-7d45489ff9
Deleted pod: webhook-operator-controller-manager-7d45489ff9-jtwzz
```

Here's the deployment that is adapted by the OLM for the operator:
https://paste.centos.org/view/a3fa0f3d

Note that it references the secret `webhook-server-cert`, which for
vanilla Kubernetes is provisioned by cert-manager. Such a secret does
not exist, hence the failure. The other one referenced by the deployment
does exist and is also mounted.

The above is for the reference application
(https://github.com/awgreene/webhook-operator/tree/olm), but also
happens with the operator I'm building. Given that this happens with the
reference application, I'm wondering if I'm not missing some step.

I'm still trying to re-read the docs and see what I'm doing wrong, but
if someone has an idea, it would be much appreciated.

Thanks,
Juca

On 01.10.20 16:07, Alexander Greene wrote:

> Hello Juraci,
>
> Thanks for using OLM. Please review OLM's existing documentation

> <https://olm.operatorframework.io/docs/advanced-tasks/adding-admission-and-conversion-webhooks/>

> detailing OLM's support for admission and conversion webhooks. Some
> quick notes based on your questions:
> - OLM will make sure that the webhook resources are created with the
> correct namespaces
> - OLM will inject the CA (likely in the wrong place

> <https://olm.operatorframework.io/docs/advanced-tasks/adding-admission-and-conversion-webhooks/#certificate-authority-requirements>,

> but OLM plans to give you a way to configure the mount point)
> - I'll need to look into the null value for `admissionReviewVersions`,
> could you create an issue against OLM

> <https://github.com/operator-framework/operator-lifecycle-manager/issues>?
>
> I have an *example webhook managed by OLM that implements a validating,
> mutating, and conversion webhook* here
> <https://github.com/awgreene/webhook-operator/tree/olm> that you can

> reference.
>
> I hope this helps!
>
> Best,
>
> Alex
>

> *Alexander W. Greene*

> Software Developer
>
> +1 412 508 5479

> greene...@gmail.com <mailto:greene...@gmail.com>

> <mailto:operator-framework%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/operator-framework/fbfd64bd-90f7-4bc9-f7e7-b6047d9b54a3%40redhat.com

> <https://groups.google.com/d/msgid/operator-framework/fbfd64bd-90f7-4bc9-f7e7-b6047d9b54a3%40redhat.com>.
>

[Alex Greene]

Hello Juraci,

A recent PR updated OLM so it would mount the webhook's CA Certs in the default Operator SDK / Kubebuilder Cert Mount point. I just ran the webhook-operator locally (please use master) and there was no issue:

```

$ oc get csvs
NAME                      DISPLAY            VERSION   REPLACES   PHASE
webhook-operator.v0.0.1   Webhook Operator   0.0.1                Succeeded

$ oc get deployments webhook-operator-webhook
NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
webhook-operator-webhook   1/1     1            1           65s

```

The full deployment yaml can be seen here: https://paste.centos.org/view/9e0e11bc

Could you share the steps you took to induce this behavior? It might help if you share the CSV of your operator as well.

Thanks,

Alex

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/e53dd77e-5b6a-3f8c-d398-85e86a7b221c%40redhat.com.

[Alexander Greene]

For context, It looks like the Deployment specifies a secret that isn’t present, but I won’t know until I see your csc.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAOuJmZbux21AF%2BnAax9zJ878fNVny-RXdos9241hqS6PWgSeVA%40mail.gmail.com.

--

Alexander W. Greene Software Developer

[Juraci Paixão Kröhling]

On 26.10.20 17:42, Alex Greene wrote:
> A recent PR
> <https://github.com/operator-framework/operator-lifecycle-manager/pull/1808/files> updated

> OLM so it would mount the webhook's CA Certs in the default Operator SDK
> / Kubebuilder Cert Mount point. I just ran the webhook-operator

> <https://github.com/awgreene/webhook-operator> locally (please use

> master) and there was no issue:

Does it mean that it will only work on future OpenShift versions? I'm
using the latest release via CRC, which certainly doesn't include this
fix. Are there known workarounds to get this working on currently
supported OpenShift versions?

I just tried your master branch, and it does fail for me. Here are the
versions I'm using:

$ crc version
CodeReady Containers version: 1.17.0+99f5c87
OpenShift version: 4.5.14 (embedded in binary)

$ oc version
Client Version: 4.4.9
Server Version: 4.5.14
Kubernetes Version: v1.18.3+5302882

$ operator-sdk version
operator-sdk version: "v1.1.0", commit:
"9d27e224efac78fcc9354ece4e43a50eb30ea968", kubernetes version:
"v1.18.2", go version: "go1.15 linux/amd64", GOOS: "linux", GOARCH: "amd64"


> ```

> $ oc get csvs
> NAME                      DISPLAY            VERSION   REPLACES   PHASE
> webhook-operator.v0.0.1   Webhook Operator   0.0.1                Succeeded
>
> $ oc get deployments webhook-operator-webhook
> NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
> webhook-operator-webhook   1/1     1            1           65s
> ```
>
> The full deployment yaml can be seen here:
> https://paste.centos.org/view/9e0e11bc
> <https://paste.centos.org/view/9e0e11bc>
>
> Could you share the steps you took to induce this behavior? It might
> help if you share the CSV of your operator as well.

Here are the steps:
https://github.com/jpkrohling/opentelemetry-operator/blob/jpkrohling/70-upgrade-to-osdk-1.1.0/CONTRIBUTING.md#testing-it-with-olm-on-openshift

You can run the exact same commands both for the operator in that
repository (opentelemetry-operator) on that branch
(jpkrohling/70-upgrade-to-osdk-1.1.0), or on your reference application.
I could reproduce the problem on both your master and olm branches.

Let me know if you can't reproduce and I'll share the resulting CSV and
deployments.

- Juca.

[Alex Greene]

Juraci,

Does it mean that it will only work on future OpenShift versions? I'm
using the latest release via CRC, which certainly doesn't include this
fix. Are there known workarounds to get this working on currently
supported OpenShift versions? 

 I just tried your master branch, and it does fail for me. Here are the

versions I'm using: 

If you are using OpenShift 4.5 you will need to update your operator to look in a different location for the certs until this PR is backported. An example workaround which allows the operator to be installed can be found here. I am not sure that this will resolve the events you are seeing because I was unable to reproduce them (more on that later).

I  followed the steps you provided to install your operator on my minikube cluster with the master branch of OLM, see the CatSrc and Sub below:

```
$kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: opentelemetry-operator-manifests
  namespace: olm
spec:
  sourceType: grpc
  image: quay.io/agreene/opentelemetry-operator-index:${BUNDLE_VERSION}
EOF

$ kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: webhook-operator-subscription
  namespace: operators
spec:
  channel: "alpha"
  installPlanApproval: Automatic
  name: opentelemetry-operator
  source: opentelemetry-operator-manifests
  sourceNamespace: olm
EOF
```

The operator pod was installed successfully, however the CSV continued to alternate between different phases because the SDK does not generate a value for the containerPort or targetPort in the CSV's WebhookDescription. Since the containerPort was not set it defaulted to 0 which causes ValidatingWebhookConfigurations and MutatingWebhookConfigurations to fail as captured below:

```

time="2020-10-27T14:02:12Z" level=error msg="Webhooks: Error creating MutatingWebhookConfiguration: MutatingWebhookConfiguration.admissionregistration.k8s.io \"mopentelemetrycollector.kb.io-gtbpc\" is invalid: webhooks[0].clientConfig.service.port: Invalid value: 0: port is not valid: must be between 1 and 65535, inclusive"

```

I was able to get around this by manually defining the containerPort and targetPort in the csv. To improve the user experience I have:

• Updated the ClusterServiceVersion's CRD Validation to require that the WebhookDescriptions ContainerPort is set to a value between 1 and 65535. Likewise, if the containerPort is omitted it will default to 443.
• Spoke with Varsha who created an issue against the SDK capturing that the ContainerPort and TargetPort are not being set.

Even after the CSV installed correctly, I could not reproduce the events that you saw:
```
$ oc get events
LAST SEEN   TYPE      REASON                    OBJECT                MESSAGE
19m         Normal    NodeHasSufficientMemory   node/minikube         Node minikube status is now: NodeHasSufficientMemory
19m         Normal    NodeHasNoDiskPressure     node/minikube         Node minikube status is now: NodeHasNoDiskPressure
19m         Normal    NodeHasSufficientPID      node/minikube         Node minikube status is now: NodeHasSufficientPID
19m         Normal    Starting                  node/minikube         Starting kubelet.
19m         Normal    NodeHasSufficientMemory   node/minikube         Node minikube status is now: NodeHasSufficientMemory
19m         Normal    NodeHasNoDiskPressure     node/minikube         Node minikube status is now: NodeHasNoDiskPressure
19m         Normal    NodeHasSufficientPID      node/minikube         Node minikube status is now: NodeHasSufficientPID
19m         Normal    NodeNotReady              node/minikube         Node minikube status is now: NodeNotReady
19m         Normal    NodeAllocatableEnforced   node/minikube         Updated Node Allocatable limit across pods
19m         Normal    RegisteredNode            node/minikube         Node minikube event: Registered Node minikube in Controller
19m         Normal    NodeReady                 node/minikube         Node minikube status is now: NodeReady
19m         Normal    Starting                  node/minikube         Starting kube-proxy.
3m8s        Warning   ResolutionFailed          namespace/operators   constraints not satisfiable: opentelemetry-operator has a dependency without any candidates to satisfy it, opentelemetry-operator is mandatory
3m22s       Warning   ResolutionFailed          namespace/operators   constraints not satisfiable: opentelemetry-operator is mandatory, opentelemetry-operator has a dependency without any candidates to satisfy it

$ oc get events -n operators
LAST SEEN   TYPE     REASON                OBJECT                                                            MESSAGE
22m         Normal   LeaderElection        configmap/9f7554c3.opentelemetry.io                               opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s_99d0b12b-6f23-4259-baa9-36003a498500 became leader
23m         Normal   Scheduled             pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Successfully assigned operators/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s to minikube
23m         Normal   Pulling               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Pulling image "gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0"
23m         Normal   Pulled                pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Successfully pulled image "gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0"
23m         Normal   Created               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Created container kube-rbac-proxy
23m         Normal   Started               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Started container kube-rbac-proxy
23m         Normal   Pulling               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Pulling image "quay.io/agreene/opentelemetry-operator"
22m         Normal   Pulled                pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Successfully pulled image "quay.io/agreene/opentelemetry-operator"
22m         Normal   Created               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Created container manager
22m         Normal   Started               pod/opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s    Started container manager
23m         Normal   SuccessfulCreate      replicaset/opentelemetry-operator-controller-manager-559c8f6cbb   Created pod: opentelemetry-operator-controller-manager-559c8f6cbb-xjh2s
23m         Normal   ScalingReplicaSet     deployment/opentelemetry-operator-controller-manager              Scaled up replica set opentelemetry-operator-controller-manager-559c8f6cbb to 1
23m         Normal   RequirementsUnknown   clusterserviceversion/opentelemetry-operator.v0.0.3               requirements not yet checked
23m         Normal   RequirementsNotMet    clusterserviceversion/opentelemetry-operator.v0.0.3               one or more requirements couldn't be found
23m         Normal   AllRequirementsMet    clusterserviceversion/opentelemetry-operator.v0.0.3               all requirements found, attempting install
23m         Normal   InstallSucceeded      clusterserviceversion/opentelemetry-operator.v0.0.3               waiting for install components to report healthy
23m         Normal   InstallWaiting        clusterserviceversion/opentelemetry-operator.v0.0.3               installing: waiting for deployment opentelemetry-operator-controller-manager to become ready: Waiting for rollout to finish: 0 of 1 updated replicas are available...
22m         Normal   InstallSucceeded      clusterserviceversion/opentelemetry-operator.v0.0.3               install strategy completed with no errors
```

You will need to define the targetPort and containerPorts for your webhooks. You will also need to do one of the following:

1. Use a newer version of OLM
2. Update the location that your operator searches for certs as shown here.

[Juraci Paixão Kröhling]

On 27.10.20 22:20, Alex Greene wrote:
> You will need to define the targetPort and containerPorts for your
> webhooks. You will also need to do one of the following:
>

> 1. Use a newer version of OLM
> 2. Update the location that your operator searches for certs as shown
> here
> <https://github.com/awgreene/webhook-operator/commit/3ef33a1b7090180bd873fb2ecbcddb9a92a79f0b>.

I tried to use the master version of OLM, but couldn't figure out how.
Perhaps I'm missing something, but I couldn't find it in the
CONTRIBUTING.md nor in the DEVELOPMENT.md files. Next, I tried `make
run-local`, but that failed too.

I then updated the code from the second option, but that didn't really
made any effect, as my operator doesn't even get started:
https://paste.centos.org/view/f09cf449

I updated the CONTRIBUTING.md from the jpkrohling/opentelemetry-operator
with all the commands I'm issuing:
https://github.com/jpkrohling/opentelemetry-operator/blob/jpkrohling/70-upgrade-to-osdk-1.1.0/CONTRIBUTING.md

It's probably something wrong that I'm doing, but I'm really stuck and
can't find how to get this solved...

Here are the versions I'm using:

$ minikube version
minikube version: v1.14.0
commit: b09ee50ec047410326a85435f4d99026f9c4f5c4
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19",
GitVersion:"v1.19.3",
GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df",
GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z",
GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19",
GitVersion:"v1.19.2",
GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d",
GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z",
GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}


- Juca.

[Alex Greene]

Juraci,

I'm going to reach out to you off list so we can debug together. After so we can update this thread so the rest of the community can benefit.

Best,

Alex

[Juraci Paixão Kröhling]

On 28.10.20 14:05, Alex Greene wrote:
> I'm going to reach out to you off list so we can debug together. After
> so we can update this thread so the rest of the community can benefit.

Thanks for taking some time today to help me on that, I really
appreciate it.

To summarize what happened:

1. the opentelemetry-operator gets deployed by OLM master, but fails to
deploy on 4.5 and 4.6 due to the cert issues we've discussed earlier in
this thread
1. to install OLM from master, I had to have the local images published
to the container registry in minikube. The easiest right now is to use
docker + `make run-local` (which will issue a `minikube docker-env`)
1. even though the operator gets deployed, the targetPort is still wrong
in my manifests, so CRs will fail to get created.

I'll create GitHub issues to track these, and I'm really happy that I
can get my operator provisioned with OLM and I'm looking forward to the
backports, so that I can publish the operator in the operator hub.

Thanks again,
Juca.