canonical / operator

Pure Python framework for writing Juju charms
Apache License 2.0
245 stars 119 forks source link

Kubernetes pod state read #166

Closed majduk closed 3 years ago

majduk commented 4 years ago

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.

relaxdiego commented 4 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

relaxdiego commented 4 years ago

Sorry this line specifically: https://github.com/relaxdiego/charm-k8s-prometheus/blob/359ec8ce4f0308b085e211c2a09a7e719d81495b/src/handlers.py#L118

majduk commented 4 years ago

Thx @relaxdiego I'm implementing that pretty much this way. I would however argue that this should be a part of the framework.

niemeyer commented 4 years ago

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.

jnsgruk commented 3 years ago

@jameinel this can probably be closed on account of the shift toward sidecar charms?

jameinel commented 3 years ago

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 .

pengale commented 3 years ago

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?

jnsgruk commented 3 years ago

I'm +1 to closing this; it feels mostly like a solved problem at this point:

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.