unit state lost following upgrade-charm

[Ian Booth]

As reported here, needs investigating.

https://github.com/canonical/operator/issues/316

<pjdc> when a charm is upgraded, is the agent's charm directory replaced entirely? i've noticed charms store stuff in there that seems to want to be persistent, and i'm curious how reliable doing that is
<pjdc> also, does are there any differences between how it's handled in CAAS and IAAS charms?
<pjdc> did some testing with a flag file and it looks like the answers are "no" and "no"
the problem i'm having seems to be happening even though afaict the pod isn't being respawned (filed https://github.com/canonical/operator/issues/316)

[Chris Johnston (cjohnston)]

I'm seeing this with the following scenario:

Deploy CK
Add a k8s model with the original controller
Deploy cs:~containers/coredns-10
Add relation for coredns/kubernetes control plane
juju trust coredns --scope=cluster # required for the new revision of coredns
juju upgrade-charm coredns --switch coredns --channel=1.24/stable

I end up with:
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
k8s-infra foundations-maas k8s_cloud/default 2.9.31 unsupported 17:47:16Z

App Version Status Scale Charm Channel Rev Address Exposed Message
coredns res:coredns-image@695a5e1 active 1 coredns 1.24/stable 18 192.152.183.63 no

Unit Workload Agent Address Ports Message
coredns/0* active idle 59.47.48.31
coredns/3 unknown lost 59.47.81.17 53/UDP,53/TCP,9153/TCP agent lost, see 'juju show-status-log coredns/3'

Offer Application Charm Rev Connected Endpoint Interface Role
coredns coredns coredns 18 1/1 dns-provider kube-dns provider

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.