RFC: state entities, replace globalKey() with .Tag().String()

[William Reade]

On Wed, Sep 24, 2014 at 5:53 AM, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi folks,
>
> I have been going through much of the code in the state package looking
> at the work to migrate all the collection keys to handle multiple
> environments.
>
> In the long and distant past (earlier this year), the Tag() method
> returned a string.  There is a second tag like thing in the state
> package called the "globalKey". This is used as a collection independent
> key into annotations, presence, settings, networks and status.  It seems
> that the only things we ever use for this are entities that have their
> own tag types.

That's not *quite* true -- relation scope keys and associated
settings, plus the network bits that Dimiter mentions, are (roughly
speaking) aggregate globalKeys. But, yeah, there's not much that's
specifically valuable about the particular forms that these keys take.

> If we ignore actions (which I don't think should bother implementing
> globalKey), then we are talking about: machine, service, unit, and network.

Apart from us wanting to be able to watch actions according to their targets?

> I propose that we replace all occurrences of the globalKey with a string
> representation of the Tag for that entity.

As long as we do this across the board -- so we also rationalise
things like hardwareCharacteristics keys (which are machine ids, not
globalKeys), and fix the relation key/id mess -- I'm very happy to see
a cleaner/saner model. And now is the right time to do it, given that
we're having to hit a very large number of keys anyway. But this is
important enough to say it twice: if we're going to do it, let's do it
*everywhere*, so we end up with *fewer* ways to reference an entity in
state -- if we can't commit to *finishing* the job, all we'll do is
make the global situation worse.

> One good part of this, is that for any element of the other collections,
> we can use the existing state.FindEntity(tag names.Tag) function.

Kind of? My perception is that we're generally using an entity's
globalKey to look up data in satellite collections, not vice versa.
Still not against it, but I don't think this is a compelling argument.

> Is anyone opposed to this change?

Only if we half-ass it :).

Cheers
William