Closed majduk closed 3 years ago
Try this in the meantime. You have everything you need in the container the operator is running in: https://github.com/relaxdiego/charm-k8s-prometheus/blob/master/src/handlers.py
Sorry this line specifically: https://github.com/relaxdiego/charm-k8s-prometheus/blob/359ec8ce4f0308b085e211c2a09a7e719d81495b/src/handlers.py#L118
Thx @relaxdiego I'm implementing that pretty much this way. I would however argue that this should be a part of the framework.
We should definitely improve the notification of units about events that happen in k8s. We need to do that in conjunction with the juju support. Will provide feedback here once we have news on that front.
@jameinel this can probably be closed on account of the shift toward sidecar charms?
With sidecar charms it becomes just as important to notify the pods about changes in the ecosystem around them. While we don't specifically need the pod/workload status, there are other events from K8s that we will want to make available to the charms.
On Mon, Apr 12, 2021 at 8:40 AM Jon Seager @.***> wrote:
@jameinel https://github.com/jameinel this can probably be closed on account of the shift toward sidecar charms https://discourse.charmhub.io/t/the-future-of-charmed-operators-on-kubernetes/4361 ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/166#issuecomment-817776597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7LZXZJL6NJMD5AWN7TTILS27ANCNFSM4LBCTMDQ .
This is a broad issue, which I think is being actively address by the Pebble work, and other related work. Do we want to keep the issue open, or close as a) broad, and b) being at least partially addressed?
I'm +1 to closing this; it feels mostly like a solved problem at this point:
<container>-pebble-ready
events are fired every time a new container is scheduled, or at least every time the Pebble API becomes available -- which is mostly likely to coincide with the container being created/recreatedcontainer.can_connect()
-- if the Pebble API is not up, the container is likely unhealthyupdate-status
hook, such as trying to reach the workload over the network, or even making API requests to K8s.It seems like the ask here is quite specific to pod_spec
charms, which are not going to see much more active development in terms of Operator Framework. The PodStatus
workaround specified here doesn't seem particularly egregious, and such a thing could be published as a charm library if prevalent enough.
The framework des not seem to have a way to read kubernetes pod state for the underalying service. It would be nice to have a way to check if the pod that is run by the given unit is already started and update unit state accordingly.