[2.7] actions UX change is not compat with 2.6

[Ryan Beisner]

The UX surrounding actions CLI has changed in a breaking way from 2.6 to 2.7, causing Charms CI gate tests to break/fail on existing action tests.

If these changes stick, and there is indeed no cli compatibility between the two versions, then libjuju and related functional tests will have to be updated accordingly, which seems like more of a major-version change experience.

[Ian Booth (wallyworld)]

Any incompatibility is unintentional.
We are using a feature flag "juju-v3" to hide the new actions UX. There is one change that is exposed to 2.6 which is that action ids are now numbers instead of UUIDs. But action ids are supposed to be opaque anyway and callers should not depend on them being any particular format. Is the change in action id the problem you are referring to or is there something else?

[John A Meinel (jameinel)]

Can you describe what the specific breaking changes are rather than just
"it broke" ? Do you have logs/etc that show the commands that fail?

On Fri, Oct 4, 2019 at 8:40 PM Ryan Beisner <email address hidden>
wrote:

> Public bug reported:
>
> The UX surrounding actions CLI has changed in a breaking way from 2.6 to
> 2.7, causing Charms CI gate tests to break/fail on existing action
> tests.
>
> If these changes stick, and there is indeed no cli compatibility between
> the two versions, then libjuju and related functional tests will have to
> be updated accordingly, which seems like more of a major-version change
> experience.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: uosci
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1846792
>
> Title:
> [2.7] actions UX change is not compat with 2.6
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1846792/+subscriptions
>

[Ryan Beisner (1chb1n)]

Indeed, we have another individual gathering the details/logs. My bug was just to make sure we put a stake in the ground around having to revert our move to 2.7.

[Eduardo Sousa (edsousa)]

The issue that I'm facing relates to the fact that the output has changed, meaning that if the 'Code' is different from 0 (successful) it doesn't return a dictionary with the key 'Stdout', which leads it to fail because it is looking for something that doesn't exist.

The output is the following in UOSCI:
2019-10-04 14:34:27 [INFO] ERROR: test_901_pause_resume (zaza.openstack.charm_tests.ceilometer.tests.CeilometerTest)
2019-10-04 14:34:27 [INFO] Run pause and resume tests.
2019-10-04 14:34:27 [INFO] ----------------------------------------------------------------------
2019-10-04 14:34:27 [INFO] Traceback (most recent call last):
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/openstack/charm_tests/ceilometer/tests.py", line 121, in test_901_pause_resume
2019-10-04 14:34:27 [INFO] with self.pause_resume(self.services):
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/contextlib.py", line 59, in __enter__
2019-10-04 14:34:27 [INFO] return next(self.gen)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/openstack/charm_tests/test_utils.py", line 283, in pause_resume
2019-10-04 14:34:27 [INFO] pgrep_full=pgrep_full)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/__init__.py", line 48, in _wrapper
2019-10-04 14:34:27 [INFO] return run(_run_it())
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/__init__.py", line 36, in run
2019-10-04 14:34:27 [INFO] return task.result()
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
2019-10-04 14:34:27 [INFO] raise self._exception
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
2019-10-04 14:34:27 [INFO] result = coro.send(None)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/__init__.py", line 47, in _run_it
2019-10-04 14:34:27 [INFO] return await f(*args, **kwargs)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/model.py", line 988, in async_block_until_service_status
2019-10-04 14:34:27 [INFO] await async_block_until(_check_service, timeout=timeout)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/model.py", line 1056, in async_block_until
2019-10-04 14:34:27 [INFO] await asyncio.wait_for(_block(), timeout, loop=loop)
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/asyncio/tasks.py", line 392, in wait_for
2019-10-04 14:34:27 [INFO] return fut.result()
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
2019-10-04 14:34:27 [INFO] raise self._exception
2019-10-04 14:34:27 [INFO] File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
2019-10-04 14:34:27 [INFO] result = coro.send(None)
2019-10-04 14:34:27 [INFO] File "/tmp/tmp.okQAPDUoyT/func-smoke/lib/python3.5/site-packages/zaza/model.py", line 1050, in _block
2019-10-04 14:34:27 [INFO] result = await c(...

[Ian Booth (wallyworld)]

I'm having trouble reproducing this. Here's what I did. I have a charm with a sample action:

#!/bin/bash
action-set result-map.time-completed="$(date)"
action-set result-map.message="Hello $(action-get who)!"
action-log hello sailor
echo Goodbye cruel world
echo This message goes to stderr >&2
exit 3

You can see it writes to both stdout and stderr and also returns exit code != 0.

I run the action and get code, stdout, stderr in the YAML as expected:

$ juju run-action ubuntu-lite/0 hello who=world --format yaml --wait
unit-ubuntu-lite-0:
  id: "4"
  message: exit status 3
  results:
    Code: "3"
    Stderr: |
      This message goes to stderr
    Stdout: |
      Goodbye cruel world
    result-map:
      message: Hello world!
      time-completed: Thu Oct 10 07:20:34 UTC 2019
  status: failed
  timing:
    completed: 2019-10-10 07:20:35 +0000 UTC
    enqueued: 2019-10-10 07:20:32 +0000 UTC
    started: 2019-10-10 07:20:34 +0000 UTC
  unit: ubuntu-lite/0

Can you tell me the steps to reproduce with a simple charm?

[Ryan Beisner (1chb1n)]

I think that they key difference here is that the existing tool doesn't specify --format yaml, and the default output/behavior changes in 2.7.

[Richard Harding (rharding)]

Right, but our comittement is that we have backward compatible machine readable formats and the non-machine readable "human" format is ok to change. In this case we'd suggest changing the existing tool to add the --format=yaml. It sets it up for success long term and adding an argument to the command is a much lighter change/touch than handling new output format. Is this not an acceptable path forward to unblock your team on this issue?

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.