On 16/09/15 12:06, Menno Smits wrote: > On 16 September 2015 at 08:41, Tim Penhey <tim.pen...@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. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
