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 <[email protected]> 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. > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
