state: Make unit ids unique. Fix #1174610

state: Make unit ids unique. Fix #1174610

This changes the way unit names are generated
when adding a new unit to a service. Before,
we used serviceDoc.UnitSeq to generate the
last part of a unit name. Now, we use the
sequence collection with a key "s#<svcname>#unit"
as the unit ids sequence (as we do for machine,
containers, etc.).

This is a schema change (removing of UnitSeq from
the service document). So it should be handled the
same way as any schema change during an upgrade,
but this CL does not do that.

I realized the sequence collection is not created
as all the other collections in state.Initialize,
so I added it there.

Also added a test to guarantee unit ids increase
each time for the same service name (like the bug
suggests and how it was before).

Per fwereade's suggestion, I changed the error
message AddUnit() returns when a service is not
found: "service is no longer alive" rather than
"service "blah" not found", and also fixed a
test that relied on that.

https://code.launchpad.net/~dimitern/juju-core/300-lp-1174610-unit-ids-unique/+merge/206765

(do not edit description out of merge proposal)

[dimitern, 2014-02-17 16:44:18]

Please take a look.

[rog, 2014-02-17 17:04:34]

On 2014/02/17 16:44:18, dimitern wrote:
> Please take a look.

Looks reasonable, but I'm concerned that it can't be applied
until we have mongo-schema-upgrade capability, which might be
a while off yet.

How about making the schema change backwardly compatible?

For example, when a service is created, we mark it with a "uses global sequence
numbering" flag
(this will be false in already existing services).
When a service is destroyed that doesn't have that flag set, we could update the
sequences collection
with the most recent unit number for that service.
When a unit is created, if allocates it from the service sequence number unless
the "uses global sequence" flag is set
in which case it allocates it using the sequences collection.

In that way, we can remain compatible with the old schema but update to the new
schema over time.

Eventually we can delete the flag and its associated logic when we don't need to
support 1.16
environments (assuming this fix goes into 1.18)

[fwereade, 2014-02-18 10:25:23]

On 2014/02/17 17:04:34, rog wrote:
> On 2014/02/17 16:44:18, dimitern wrote:
> > Please take a look.
> 
> Looks reasonable, but I'm concerned that it can't be applied
> until we have mongo-schema-upgrade capability, which might be
> a while off yet.
> 
> How about making the schema change backwardly compatible?
> 
> For example, when a service is created, we mark it with a "uses global
sequence
> numbering" flag
> (this will be false in already existing services).
> When a service is destroyed that doesn't have that flag set, we could update
the
> sequences collection
> with the most recent unit number for that service.
> When a unit is created, if allocates it from the service sequence number
unless
> the "uses global sequence" flag is set
> in which case it allocates it using the sequences collection.
> 
> In that way, we can remain compatible with the old schema but update to the
new
> schema over time.
> 
> Eventually we can delete the flag and its associated logic when we don't need
to
> support 1.16
> environments (assuming this fix goes into 1.18)

This isn't quite enough. While clients still have direct DB access (ie until
past 1.18) we need to *always* read from, and write to, the old location, as
well as the new one -- and this actually renders any change pointless, because
we could *always* have an old client removing then creating a new service. We
actually *can't* do this yet. Sorry Dimiter, my enthusiasm for fixing something
that annoyed hazmat got me over-excited and I failed to think it through.

FWIW this *is* exactly what we *should* do once we have mongo fully locked
down...

[fwereade, 2014-02-18 10:25:48]

On 2014/02/18 10:25:23, fwereade wrote:
> On 2014/02/17 17:04:34, rog wrote:
> > On 2014/02/17 16:44:18, dimitern wrote:
> > > Please take a look.
> > 
> > Looks reasonable, but I'm concerned that it can't be applied
> > until we have mongo-schema-upgrade capability, which might be
> > a while off yet.
> > 
> > How about making the schema change backwardly compatible?
> > 
> > For example, when a service is created, we mark it with a "uses global
> sequence
> > numbering" flag
> > (this will be false in already existing services).
> > When a service is destroyed that doesn't have that flag set, we could update
> the
> > sequences collection
> > with the most recent unit number for that service.
> > When a unit is created, if allocates it from the service sequence number
> unless
> > the "uses global sequence" flag is set
> > in which case it allocates it using the sequences collection.
> > 
> > In that way, we can remain compatible with the old schema but update to the
> new
> > schema over time.
> > 
> > Eventually we can delete the flag and its associated logic when we don't
need
> to
> > support 1.16
> > environments (assuming this fix goes into 1.18)
> 
> This isn't quite enough. While clients still have direct DB access (ie until
> past 1.18) we need to *always* read from, and write to, the old location, as
> well as the new one -- and this actually renders any change pointless, because
> we could *always* have an old client removing then creating a new service. We
> actually *can't* do this yet. Sorry Dimiter, my enthusiasm for fixing
something
> that annoyed hazmat got me over-excited and I failed to think it through.
> 
> FWIW this *is* exactly what we *should* do once we have mongo fully locked
> down...

so, to be explicit, this sadly does not lgtm

[fwereade, 2014-02-18 10:26:37]

On 2014/02/18 10:25:48, fwereade wrote:
> On 2014/02/18 10:25:23, fwereade wrote:
> > On 2014/02/17 17:04:34, rog wrote:
> > > On 2014/02/17 16:44:18, dimitern wrote:
> > > > Please take a look.
> > > 
> > > Looks reasonable, but I'm concerned that it can't be applied
> > > until we have mongo-schema-upgrade capability, which might be
> > > a while off yet.
> > > 
> > > How about making the schema change backwardly compatible?
> > > 
> > > For example, when a service is created, we mark it with a "uses global
> > sequence
> > > numbering" flag
> > > (this will be false in already existing services).
> > > When a service is destroyed that doesn't have that flag set, we could
update
> > the
> > > sequences collection
> > > with the most recent unit number for that service.
> > > When a unit is created, if allocates it from the service sequence number
> > unless
> > > the "uses global sequence" flag is set
> > > in which case it allocates it using the sequences collection.
> > > 
> > > In that way, we can remain compatible with the old schema but update to
the
> > new
> > > schema over time.
> > > 
> > > Eventually we can delete the flag and its associated logic when we don't
> need
> > to
> > > support 1.16
> > > environments (assuming this fix goes into 1.18)
> > 
> > This isn't quite enough. While clients still have direct DB access (ie until
> > past 1.18) we need to *always* read from, and write to, the old location, as
> > well as the new one -- and this actually renders any change pointless,
because
> > we could *always* have an old client removing then creating a new service.
We
> > actually *can't* do this yet. Sorry Dimiter, my enthusiasm for fixing
> something
> > that annoyed hazmat got me over-excited and I failed to think it through.
> > 
> > FWIW this *is* exactly what we *should* do once we have mongo fully locked
> > down...
> 
> so, to be explicit, this sadly does not lgtm

(it's a shame to lose the incidental fixes though -- can they be easily
extracted?)