Problem
I'd like to be able to edit the spec of any deployment the eventing CR creates. This includes
- eventing-controller
- eventing-webhook
- imc-controller
- imc-dispatcher
- sources-controller
Ideally I'd like to be able to also configure the default-broker-filter/ingress deployments that get created on labeling a namespace for eventing injection, but I believe that part is done by the controller and not the operator itself.
Persona:
Which persona is this feature for?
I'd argue all of the personas could benefit from this as it'd make it easier to provide HA.
Exit Criteria
When installing the eventing CR I should be able to edit the deployment spec of all deployments that CR would create
(Stretch) enable this for the auto-injected default broker deployments.
Time Estimate (optional):
Not sure how hard it'd be since I don't know the codebase all that well, but I'd estimate a 2-3 days given my experience writing mutating webhooks.
Additional context (optional)
This mainly stems from the fact that the mutating webhook being down can break a lot of our system in dev. We have ephemeral worker nodes and if the webhook is on one of those there's inevitable downtime. This could be remedied by allowing more replicas, but that doesn't seem to be possible via this operator.
Problem
I'd like to be able to edit the spec of any deployment the eventing CR creates. This includes
Ideally I'd like to be able to also configure the default-broker-filter/ingress deployments that get created on labeling a namespace for eventing injection, but I believe that part is done by the controller and not the operator itself.
Persona:
Which persona is this feature for?
I'd argue all of the personas could benefit from this as it'd make it easier to provide HA.
Exit Criteria
When installing the eventing CR I should be able to edit the deployment spec of all deployments that CR would create
(Stretch) enable this for the auto-injected default broker deployments.
Time Estimate (optional):
Not sure how hard it'd be since I don't know the codebase all that well, but I'd estimate a 2-3 days given my experience writing mutating webhooks.
Additional context (optional)
This mainly stems from the fact that the mutating webhook being down can break a lot of our system in dev. We have ephemeral worker nodes and if the webhook is on one of those there's inevitable downtime. This could be remedied by allowing more replicas, but that doesn't seem to be possible via this operator.