Running upgrade steps for units
Ian Booth
ian.booth at canonical.com
Wed Sep 16 04:45:31 UTC 2015
On 16/09/15 12:06, Menno Smits wrote:
> On 16 September 2015 at 08:41, Tim Penhey <tim.penhey at canonical.com> wrote:
>
>> On 15/09/15 19:38, William Reade wrote:
>>> Having the machine agent run unit agent upgrade steps would be a Bad
>>> Thing -- the unit agents are still actively running the old code at that
>>> point. Stopping the unit agents and managing the upgrade purely from the
>>> machine would be ok; but it feels like a lot of effort for very little
>>> payoff, so I'm most inclined to WONTFIX it and spend the energy on agent
>>> consolidation instead.
>>
>> This still leaves us with the problem of the two upgrade steps that were
>> written to update the uniter state file, and how to handle this.
>>
>
> If the work that these upgrade steps did is fairly trivial we could have
> the unit agents run a function which does the upgrade work as it comes up,
> before workers are started. This might be an acceptable solution if we're
> going to merge machine and unit agents soon[1] anyway.
>
> I had thought it might be reasonably easy to get the upgrade machinery
> working within the unit agent but now that I've looked at the code I can
> see that it's a fairly major undertaking (to do it Right at least).
>
That would work, since the upgrade steps are trivial. They read the local state
file (yaml) and update a setting and write the file back out. The uniter could
just call the upgrade methods directly.
More information about the Juju-dev
mailing list