httprequest-lego-k8s does not go into error state if external_hostname is not set on traefik

[Thanhphan1147]

Bug Description

Hi, when using httprequest-lego-k8s to provide certificates to traefik-k8s, I noticed that even though I haven't set the external_hostname config value for traefik-k8s, the charm still went ahead and create the request using the traefik's LB IP address which failed, but this failure does not make the charm go into error/blocked state and the charm went into an active state instead.

In this case the charm should go into blocked/error state to let the user know that it's not possible unless traefik-k8s is configured with external-hostname

To Reproduce

1. juju deploy traefik-k8s --channel=latest/edge
2. juju deploy httprequest-lego-k8s
3. juju integrate traefik-k8s httprequest-lego-k8s

Environment

channel=stable

Relevant log output

Here is an extract of juju debug-log from one of our deployments.

2024-04-26T08:59:07.310Z [container-agent] 2024-04-26 08:59:07 ERROR juju-log certificates:43:     2024/04/26 08:59:07 Could not obtain certificates:
2024-04-26T08:59:07.312Z [container-agent] 2024-04-26 08:59:07 ERROR juju-log certificates:43:          acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:unsupportedIdentifier :: NewOrder reques
t included invalid non-DNS type identifier: type "ip", value "10.142.2.170"
2024-04-26T08:59:07.314Z [container-agent] 2024-04-26 08:59:07 ERROR juju-log certificates:43: Failed to execute lego command

### Additional context

_No response_

[gruyaume]

The charm status only depends on what it can control, not on what TLS requirers do. For instance, httprequest could be integrated to multiple TLS requirers, and it should likely not go to blocked status if one of them does something wrong.

Maybe we could improve some of the logging, but I doubt we would want to implement this as requested.

I switched the issue type from bug to enhancement.

[Thanhphan1147]

I see, thanks for the explaination! I agree with the improved logging proposal, maybe we can keep the charm's status as active but put a short text in the charm's status message. The idea is to notify the user that the request has failed and that some action needs to be done on the user's side.