Running upgrade steps for units

[William Reade]

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.

Don't recall deciding not to execute upgrade steps on unit agents, but I
can equally see why the agent code made that a rational decision, so, ehh.
I suspect we should have had some tests that the upgrade framework rejected
unit agent tags, though.

Cheers
William

On Tue, Sep 15, 2015 at 7:13 AM, Tim Penhey <tim.penhey at canonical.com>
wrote:

> Hi William and Menno,
>
> I've been investigating this bug:
>         https://bugs.launchpad.net/juju-core/+bug/1494070
>
> The upgrade steps were never planned to be executed for unit agents,
> only on machine agents, but there are two upgrade steps identified in
> this bug where they were clearly expecting to run for units.
>
> Obviously there is a need to be able to run steps for units, but I don't
> think we should add it to unit agents, especially given the desire to
> merge the agents in the near future.
>
> What I do think we should do is provide a helper function inside the
> upgrade package that will run a step for each unit passing in the unit tag.
>
> So what we really need is the ability for the API as connected to by a
> machine to ask for a list of units that should be running on that
> machine. Do we have an API or state function for this already? I haven't
> found on in my cursory look just now, but I thought I'd raise this and
> do a sanity check at the same time.
>
> There would be clear limitations for the upgrade steps for the units as
> the API connection as as a machine agent.  However both the upgrade
> steps identified so far are just updating local disk state based on
> other disk state for a specified unit.
>
> Firstly does this sound like a reasonable approach?
>
> Tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150915/67a9ab2f/attachment.html>