juju run broke after an upgrade

[Curtis Hovey]

There have been two cases where juju run broke after an upgrade. The upgrade tests could exercise "juju run" to prove the command continues to work

[Curtis Hovey (sinzui)]

We can run this command as a part of deploy to verify run/ssh operates after we deploy a stack. We would treat return code 0 as a requirement for success:
     juju run --all uname

In the case of upgrade, after the upgrade has happened, we would run
     juju run --all uname
again to ensure it still works.

So success of deploy and upgrade depend on status being started and "run" working.

[Curtis Hovey (sinzui)]

Running
     juju run --format json --all uname
will return json like this
   [{"MachineId":"0","Stdout":"Linux\n"},{"MachineId":"1","Stdout":"Linux\n"},{"MachineId":"2","Stdout":"Linux\n"}]

when there is an error, the machine's dict will contain keys for "ReturnCode" and "Stderr". We can check for ReturnCode, but in case it is changed in the future to be included when the value is zero, we might want to do
    for machine in response:
         if machine.get('ReturnCode', 0) != 0:
            raise Exception('juju run on machine %s returned %d: %s' (
                machine['MachineId'], machine['ReturnCode'], machine['Stderr'])

As we want to call run before and after the call to upgrade in the complex nesting of deploy_stack._deploy_stack(), we will want a helper function that calls env.juju('run', [ '--format', 'json', '--all', 'uname']), parses the output and checks the content. We can write a test for the helper function.