Running upgrade steps for units

[Tim Penhey]

Here is an approach that will work for now:

http://reviews.vapour.ws/r/2672/diff/# - a 1.25 based branch

If we are happy with this, I can forward port to master and add the
other upgrade step.

Also, do we want to back port to 1.24?

When is the 1.24.6 release?

Tim

On 16/09/15 16:45, Ian Booth wrote:
> 
> 
> 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.
>