ingress charm can get stuck if LoadBalancer IP is slow to provision

[ca-scribner]

Bug Description

If the cluster LoadBalancer is slow to provide our service with an IP (either because it is slow, or because the cluster doesn't have one provisioned atm), our ingress charm has at least two issues:

• if we are related to a TLS provider and do not have a external_hostname config value set, we need the LoadBalancer IP to request certs
• _sync_all_resources() has an _is_ready() guard that, if the LoadBalancer IP is unavailable will prevent the creation of ingress resources (Gateway/HTTPRoute) and put the charm status as Blocked

For both these problems, we have no guarantee that our charm will be woken up when the LoadBalancer service obtains an ip. For example:

• cluster is provisioned but loadbalancer provisioner is not set up
• charm starts, creates a LoadBalancer service, and waits for an IP but none is provided
• cluster LoadBalancer provisioner is configured. Our LoadBalancer service is provided an IP
• (nothing happens here to wake our charm, which stays non-functional)

This is discussed more in this thread.

Ideally, we'd have a k8s watcher on the service that could wake the charm when our Service changed. That's theoretically possible with Pebble notices, but not sure if its practical.

Not directly related to the root cause here, but in hindsight I think we should what the _is_ready() guard blocks in _sync_all_resources. Gateway/HTTPRoute resources can be created regardless of whether the LoadBalancer service has an IP yet - we should just create them anyway and use _is_ready() just to set the charm status. There's no downside to do this, and it feels more kubernetes native

To Reproduce

see above

Environment

Relevant log output

-

Additional context

No response