worker/uniter/operation/runcommands.go:68... uses `context.ErrReboot` to indicate "there is a valid response value that should be handled, but we also need to queue a reboot". The change throws away the valid response.
On Thu, Aug 11, 2016 at 1:47 AM, Martin Packman < martin.pack...@canonical.com> wrote: > Nicholas was struggling today to land his snapcraft pull request: > > <https://github.com/juju/juju/pull/5956> > > As a side effect this updates some dependencies, including a couple of > changes to juju/utils, which it turns out, causes > UniterSuite.TestRebootFromJujuRun to fail. > > Here's a run of master, which passes: > > <http://paste.ubuntu.com/22963025/> > > Then the failure, just with utils updated to rev 8a9dea0: > > <http://paste.ubuntu.com/22965595/> > > I'm not clear on how the new exec behaviour is actually causing the > test failure: > > <https://github.com/juju/utils/pull/203/files> > > So, any insights or suggestions welcome. > > > Note, the log also includes two other errors, but they appear in both > the passing and failing log, so are not actually affecting the test > outcome: > > [LOG] 0:01.631 ERROR juju.apiserver Unable to prime > /tmp/check-1447535164350529303/5/logsink.log (proceeding anyway): > chown /tmp/check-1447535164350529303/5/logsink.log: operation not > permitted > > This code should probably just not be being run under unit test, is > assuming root privs? > > [LOG] 0:03.078 ERROR juju.worker.uniter.context updating agent status: > cannot set invalid status "rebooting" > > The status setting code in uniter is a twisty confusion, I don't know > why this is happening or where the error is being swallowed. > > Martin > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
