Create new LoadBalancer svc instead of modifying the Juju ClusterIP svc about traefik-k8s-operator HOT 5 CLOSED

Renaming/rewording this bug with new information.

from traefik-k8s-operator.

FYI we're affected by this issue on our COS deployment, currently more or less every week we loose our Octavia LB and have to manually patch the service (remove the lb ID annotation) and make a DNS PR to change the IP and sometimes do a FW PR

from traefik-k8s-operator.

Waiting for followup from juju team. @wallyworld

from traefik-k8s-operator.

Hi Everyone,

Thanks for providing the information. As from the Juju's teams perspective I agree with the current description of this issue in that the charm should not be modifying any resource made by Juju in the Kubernetes cluster. Juju operates in a reconciliation loop where it constantly drives the desired state back into the external system. By modifying our own resources we are going to end up in a situation where we ping pong the change around.

The better approach would be for the charm to provision their own service. Juju will detect this and also clean up this service on behalf of the charm when the charm is removed from a controller.

In an ideal world we very much understand that we need to model ingress and load balancers into Juju and that will give everyone the best of both worlds.

from traefik-k8s-operator.

Juju used to allow an application to be deployed such that the type of k8s service created for it could be specified. Unfortunately the transition to sidecar charms saw that capability go away. We have at carious times internally discussed ideas around allowing resources created by Juju to be patched, but as Tom says, this is dangerous and would be a last resort that should be avoided if there's a viable alterative. We really do want to properly model ingress and other missing aspects of the network model offered by Juju, but that's a way off.

from traefik-k8s-operator.