caasoperator: Expose Juju unit name

Bug #1894782 reported by Haw Loeung
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Wishlist
Unassigned

Bug Description

Hi,

At present, for CAAS units, there is nothing about the unit name (JUJU_UNIT). There is 'HOSTNAME' (e.g. content-cache-749bd49549-hgfhv) which is the name of the K8s pod, but would be nice to also expose the unit name, e.g. content-cache/X.

There doesn't appear to be a workaround, tried setting something like envConfig 'UNIT': self.unit.name (operator framework) but that causes an endless loop of pods being provisioned/deployed because the pod spec changes each iteration.

Revision history for this message
Haw Loeung (hloeung) wrote :

Or is this operator that provides it?

https://paste.ubuntu.com/p/w6zH3QhZpY/

summary: - caasoperator: Expose unit name
+ caasoperator: Expose Juju unit name
Revision history for this message
Haw Loeung (hloeung) wrote :

Workaround I'm using is in the docker images' entrypoint script:

| export JUJU_UNIT=$(basename /var/lib/juju/tools/unit-* | sed -e 's/^unit-//' -e 's/-\([0-9]\+\)$/\/\1/')

See https://git.launchpad.net/~hloeung/charm-k8s-content-cache/tree/docker/entrypoint.sh

Revision history for this message
Haw Loeung (hloeung) wrote :
Revision history for this message
Stuart Bishop (stub) wrote :

spec.nodeName is a workaround, as it can only be mapped to the unit name if the pods are stateful. In most cases the pod name is essentially random (but unique, so I think works for Haw's use case).

Pen Gale (pengale)
Changed in juju:
status: New → Triaged
importance: Undecided → Wishlist
tags: added: field-feedback k8s
Revision history for this message
Haw Loeung (hloeung) wrote :

Any chance we can revisit this? With sidecar, I can no longer use K8s special fields as we're no longer controlling what gets put in the pod spec.

tags: added: sidecar-charm
Revision history for this message
Haw Loeung (hloeung) wrote :

These:

| 'JUJU_NODE_NAME': {'field': {'api-version': 'v1', 'path': 'spec.nodeName'}},
| 'JUJU_POD_NAME': {'field': {'api-version': 'v1', 'path': 'metadata.name'}},
| 'JUJU_POD_NAMESPACE': {'field': {'api-version': 'v1', 'path': 'metadata.namespace'}},
| 'JUJU_POD_IP': {'field': {'api-version': 'v1', 'path': 'status.podIP'}},
| 'JUJU_POD_SERVICE_ACCOUNT': {'field': {'api-version': 'v1', 'path': 'spec.serviceAccountName'}},

Revision history for this message
Haw Loeung (hloeung) wrote :

Also filed a bug against the Operator framework - https://github.com/canonical/operator/issues/541

Revision history for this message
Ian Booth (wallyworld) wrote :

Yeah, sidecar charms don't currently allow the same level of pod configuration as operator style charms.

Note though that JUJU_POD_IP can be fetched using network-get and inspecting the bind addresses.

The service account name and pod name are the same as that of the application, so these can be inferred without needing to be explicitly set.

And is JUJU_NODE_NAME the same as hostname?

We could introduce extra hook env vars to make it easier for charm authors to get such data. Maybe we need to agree on a standard set of extra env vars we want to include in the hook context for a k8s charm.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.