charm upgrade from charm store can leave units out-of-date and unfixable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pyjuju |
Triaged
|
Low
|
Unassigned |
Bug Description
The "upgrade-charm" command does (among other things) the following.
[1]
Abort if the latest charm id matches the *service*'s charm id. This only happens with charm store charms; local charms will have their version incremented, and will be republished with a new id.
[2]
Mark for upgrade only those units currently in a "started" state. In addition, any unit which detects an upgrade flag while not in a "started" state will discard the instruction.
So, consider the situation in which we have some-service/0 (started) and some-service/1 (start_error, say), running cs:precise/
The problem also exists for local charm repositories, but has a lower impact because it does have a workaround: that is, you can just manually upgrade as many times as it takes for the upgrade to be processed by every machine.
I'm not sure exactly what we should do about this. It seems a touch lumpen to demand that some agent repeatedly reset upgrade flags for units whose charms don't match their service's, but on the other hand I can't actually think of anything better.
Changed in juju: | |
importance: | Undecided → High |
milestone: | none → florence |
Changed in juju: | |
milestone: | florence → galapagos |
Changed in juju: | |
milestone: | 0.6 → 0.7 |
Changed in juju: | |
milestone: | 0.7 → 0.8 |
Changed in juju: | |
importance: | High → Low |
> Mark for upgrade only those units currently in a "started" state. In addition, any
> unit which detects an upgrade flag while not in a "started" state will discard the instruction.
Please let me know if I'm going completely off track, but as far as I could perceive in the
description, this is actually the only bug being reported. There's no reason for the unit to
_discard_ the instruction. The upgrade flag is a persistent node in the tree. Once it leaves
the error state and goes back to a normal running state, it should see if there's an upgrade
flag up and proceed as usual.
> I'm not sure exactly what we should do about this. It seems a touch lumpen to demand that
> some agent repeatedly reset upgrade flags for units whose charms don't match their
> service's, but on the other hand I can't actually think of anything better.
We can't do that. The upgrade flag design is precisely addressing the need to upgrade units
individually and at one's discretion.