This issue was encountered during the integration of the admission-webhook rock into Charmed Kubeflow, tracked in this issue.
Running the integration tests returns the charm in a blocked state. Looking at the Juju logs, it seems that there are multiple instances of the webhook executable running at the same time. Indeed, after connecting to the admission-webhook container with juju ssh --container admission-webhook admission-webhook/0, and running pebble plan, I get this output:
We can see that the OCI image has a service named base-admission-webhook, defined here.
Meanwhile, the charm code creates another service named admission-webhook, created here. It seems that there is a conflict between these 2 services that run the same executable, and only 1 service should be created.
Bug Description
This issue was encountered during the integration of the
admission-webhook
rock into Charmed Kubeflow, tracked in this issue.Running the integration tests returns the charm in a
blocked
state. Looking at the Juju logs, it seems that there are multiple instances of thewebhook
executable running at the same time. Indeed, after connecting to theadmission-webhook
container withjuju ssh --container admission-webhook admission-webhook/0
, and runningpebble plan
, I get this output:We can see that the OCI image has a service named
base-admission-webhook
, defined here.Meanwhile, the charm code creates another service named
admission-webhook
, created here. It seems that there is a conflict between these 2 services that run the same executable, and only 1 service should be created.To Reproduce
admission-webhook-operator
repo.tox -e integration --model kubeflow
Environment
Python:
3.8
Juju:3.4.5
Microk8s:1.29
Relevant Log Output
Additional Context
This issue could be fixed by ensuring that only 1 service is created, by having the same name value in both places.