Instance key stability in refresh requests

[Maximiliano Bertacchini]

In order to collect, aggregate, and track accurate metrics & kpis for parallel installs, i.e. multiple instances of the same charm in a model, the snap store needs *stable* instance keys across refresh requests over time. Instance keys are currently randomly generated for each context item on each request, afaik.

[Heather Lanigan (hmlanigan)]

PR for juju 3.0
https://github.com/juju/juju/pull/13379

When the refresh action is called, a unique, stable instance-key will be set, equivalent to <model-uuid>:a#<application-name>. Any instance-key which is only a uuid, should not be considered stable.

All charmhub metrics work in juju will be back ported to 2.9 shortly.

[William Grant (wgrant)]

I'm not comfortable with the privacy implications of this specific change: Juju now reports application names, which may well be sensitive or potentially even PII.

Consider instead a privacy-preserving implementation like snapd's genInstanceKey, which hashes with a persistent client-specific salt: https://github.com/snapcore/snapd/blob/master/store.store_action.go#L268

Also note that instance keys are local to a single reporting entity (in Juju's case, a model), so there's no need to include the model UUID.

[Heather Lanigan (hmlanigan)]

Investigating how snap does genInstanceKey.

[Heather Lanigan (hmlanigan)]

Updated in https://github.com/juju/juju/pull/13391 - which will be forward ported to develop once it lands.