Owner: Architect:

_<Architect is responsible for completing this section to define the
details of the story>_

Story (Required)

As an OpenShift user, I would like isolation between deployed primaza agents so that I may run multiple instances of them without interference from each other.

Background (Required)

In our current state, all of our webhooks are cluster scoped. This means means that clusters with multiple agents installed in separate namespaces will see interference between these agents, especially in webhook behavior. This has caused us to move some behavior that should ideally be done in a webhook to instead be done in the reconciler.

It's possible to have namespaced-scoped mutation and validation webhooks (but not conversion webhooks), though the process for getting them to work isn't going to be straightforward.

Glossary

<List of new terms and definition used in this story>

Out of scope

Don't implement new webhooks or new kinds of webhooks in this story; just use what we already have.

In Scope

<Defines what is included in this story>

Approach(Required)

To get this to work, we need to make the following changes:

• Create ValidationWebhookConfiguration and MutationWebhookConfiguration entries during operator setup, rather than as a part of our pre-applied yaml. This is because we need to have one entry in the webhooks array for each namespace an agent is installed into, rather than one entry that catches everything in-cluster.
• Set up label selectors on the webhook configuration. These selectors need to be distinct for each namespace; they shouldn't be identical for each agent. Long-term, we should move to using CEL selectors, but since those are currently in alpha, we shouldn't rely on them. Until they're stabilized, we need to use label selectors instead.
• Label incoming resources pushed from a primaza cluster with their namespace. These need to match the label selectors we set up in the webhook configuration for that namespace.

Demo requirements(Required)

_<Description of demo which would show the value of this story. Any demo
should also be included as part of the acceptance criteria.>_

Dependencies

_<Describes what this story depends on. Dependent Stories and EPICs should
be linked to the story.>_

Edge Case

_<Describe edge cases to consider when implementing the story and defining
tests>_

Acceptance Criteria

Development: If a cluster has two instances of the same agent deployed, then deploying a resource owned by that agent in one namespace should not be observable by the other agent.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied