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

[Tim Penhey]

On 24/09/14 18:02, Dimiter Naydenov wrote:
> On 24.09.2014 06:53, Tim Penhey 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.
> 
>> If we ignore actions (which I don't think should bother
>> implementing globalKey), then we are talking about: machine,
>> service, unit, and network.
> 
>> I propose that we replace all occurrences of the globalKey with a
>> string representation of the Tag for that entity.
> 
> Why? Global keys are a shorter than tags, and in several places we use
> fast regular expression searches using a prefix based on the global key.
> So instead of having "m#0#n#juju-public" as global key for a port
> ranges document, we'll have to use "machine-0<*>network-juju-public",
> where "<*>" is some unambiguous separator. The same is valid for
> service settings - "s#wordpress" will become "service-wordpress".

Sorry, but this is terrible.  The regex searches we have are needlessly
complicated, and the documents should have real fields rather than
disassembling the _id field.  I think that having a slightly longer
value stored in mongo is worth the code when it means we go from having
two ways to identity an entity down to one.

> I'd rather have a transparent transformation in place to convert
> global keys to tags, where needed (the only special case I can think
> of is relation tags "relation-123", which cannot be converted back to
> relation names (e.g "wordpress:db mysql:server") without a DB lookup).

I'd rather just have one way to identify an entity in state.

> Also, what I didn't understand is how using tags as global keys will
> solve the case with multiple environments in the same DB?

It doesn't, it is just code cleanup that I think we should do.

Tim