ValueError: No JSON object could be decoded

[David Britton]

00:15:54.554 File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 400, in run_layer
00:15:54.554 setup_layer(options, layer, setup_layers)
00:15:54.554 File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 708, in setup_layer
00:15:54.554 setup_layer(options, base, setup_layers)
00:15:54.554 File "/usr/lib/python2.7/dist-packages/zope/testrunner/runner.py", line 713, in setup_layer
00:15:54.554 layer.setUp()
00:15:54.554 File "./tests/helpers/layers.py", line 62, in setUp
00:15:54.554 cls.server.ensure()
00:15:54.554 File "./tests/helpers/server.py", line 75, in ensure
00:15:54.554 self._deployment.sentry.wait(self._timeout)
00:15:54.554 File "/usr/lib/python2.7/dist-packages/amulet/sentry.py", line 310, in wait
00:15:54.554 status = self.unit[unit].juju_agent()
00:15:54.554 File "/usr/lib/python2.7/dist-packages/amulet/sentry.py", line 151, in juju_agent
00:15:54.554 return self._run_unit_script("juju_agent.py", working_dir=".")
00:15:54.554 File "/usr/lib/python2.7/dist-packages/amulet/sentry.py", line 146, in _run_unit_script
00:15:54.554 return json.loads(output)
00:15:54.554 File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
00:15:54.554 return _default_decoder.decode(s)
00:15:54.554 File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
00:15:54.554 obj, end = self.raw_decode(s, idx=_w(s, 0).end())
00:15:54.554 File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
00:15:54.554 raise ValueError("No JSON object could be decoded")
00:15:54.554 ValueError: No JSON object could be decoded

Might be an upstream amulet bug?

[Chris Glass (tribaal)]

Liam saw the same problem and determined it to be because his DNS resolution made sudo complain, and the "unable to resolve host XXX" ended up in the output json ends up trying to decode:

amulet/sentry.py", line 146, in _run_unit_script calls amulet's "juju_agent.py" with sudo, and if sudo complains about resolving its DNS name, it will appear in the output.

I'm unsure where to fix this in the CI environment - maybe somebody with a better knowledge of our CI setup could try it out?

[David Britton (dpb)]

I'm not sure we reliably can. Amulet could be run from an LXC container
that are still affected by bug #1328269 (which can be one-off fixed, but
the next one we spin up will still have the issue).

[David Britton (dpb)]

I suppose there is a workaround in bug #1328269 that we could run on the
machine before we execute. stub has already started incorporating that
into charms.

On Wed, Sep 23, 2015 at 7:19 AM, David Britton <email address hidden>
wrote:

> I'm not sure we reliably can. Amulet could be run from an LXC container
> that are still affected by bug #1328269 (which can be one-off fixed, but
> the next one we spin up will still have the issue).
>

--
David Britton <email address hidden>

[David Britton (dpb)]

Looks to me like https://github.com/juju/amulet/commit/e7fd1d460ba42c1a1b20f29ea75d285613b96c83 introduced the error. Should we just throw away stderr, since we are expecting machine parseable output?

[Tim Van Steenburgh (tvansteenburgh)]

Pending review/release: https://github.com/juju/amulet/pull/98