Actions should accept files as a parameter

[Marco Ceppi]

A lot of common actions produce an artifact in which the user is expected to download a file. Likewise, actions often times need a file to operate properly. The result is a less than ideal UX. Take the following examples:

```
$ juju run-action etcd/0
Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580c
$ juju show-action-output b46d5d6f-5625-4320-8cda-b611c6ae580c
results:
  copy:
    cmd: juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
      .
  snapshot:
    path: /home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
    sha256: 1dea04627812397c51ee87e313433f3102f617a9cab1d1b79698323f6459953d
    size: 68K
status: completed
```

Alternatively, it'd be a better user experience if, there was an `action-set --file <key>=<path>`. pseudo code for the action would look as follows:

```
action-set --file snapshot=/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
action-set foo=bar
```

```
$ juju run-action etcd/0
Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580c
$ juju show-action-output b46d5d6f-5625-4320-8cda-b611c6ae580c
results:
  foo: bar
files:
  snapshot:
    file: etcd-snapshot-2016-11-09-02.41.47.tar.gz
    sha256: 1dea04627812397c51ee87e313433f3102f617a9cab1d1b79698323f6459953d
    size: 68K
status: completed
```

At this point in time the user could download an attachment with a new juju command (either get-action-attachment or get-action-output, probably the latter)

```
Usage: juju get-action-output [options] <action ID> <file ID> [path]

Summary:
Get results of an action by action ID and file ID.

Options:
-m, --model (= "")
    Model to operate in. Accepts [<controller name>:]<model name>

Details:
Download a file returned by an action with the given action and file ID. A partial
action ID may also be used. File will be downloaded to the current directory unless
a path is provided.
```

Conversely, there are scenarios where a user would need to attach a file in order to complete an action. Today, zero byte resources are supplied with charms and the user is instructed to attach a resource to the charm, then run an action. Example below:

```
juju attach etcd snapshot=./etcd-snapshot-2016-11-09-02.41.47.tar.gz
juju run-action new-etcd/0 restore
```

Instead, we should add a "file" type to actions.yaml json schema:

```
restore:
  description: "Restore an etcd cluster's data from a snapshot tarball."
  params:
    snapshot:
      type: file
      extension: tar.gz
      description: Path on disk to save any pre-existing data
  required:
   - snapshot
```

The file type does not have a default but expects an extension which outlines the accepted file extension attachment. The extension key provided but with a null value means there should be no extension checking. The UX would look as such

```
$ ls -lh
total 68k
-rw-rw-r-- 1 marco marco 68k etcd-snapshot.tar.gz
-rw-rw-r-- 1 marco marco 0b etcd-snapshot.txt
$ juju run-action etcd/0 restore snapshot=etcd-snapshot.tar.gz
Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580d
$ juju run-action etcd/0 restore snapshot=not-a-file.null
Action failed: snapshot file does not exist
$ juju run-action etcd/0 restore snapshot=etcd-snapshot.txt
Action failed: wrong file type for snapshot
```

On the charm side, `action-get` for a file type would fetch the blob from the controller and place it on disk (much like resources) and return the path on disk.

```
echo $(action-get snapshot)
/var/lib/juju/agents/etcd-0/resource/b46d5d6f-5625-4320-8cda-b611c6ae580d/snapshot.tar.gz
```

Finally, there should be a consideration for garbage collection, either after the action concludes or after a period of time, where these objects are removed from the system.

[Ryan Beisner (1chb1n)]

+1, another example is the Tempest charm: An action executes an OpenStack functional test suite. The user then scps the results blob out of the unit.

[Alvaro Uria (aluria)]

This also affects Operations teams that don't have ssh access but need limited privileges to collect e.g. backups. When running a "backup" action, the action will tell the "juju scp" command needed to retrieved the backup file.

The bug is classified "High". Is there any chance this feature could be added to the roadmap?

[Pen Gale (pengale)]

We just had our biannual no holds barred roadmap derby at the beginning of this month, and we're pretty solidly booked for this cycle, so I'd say that there isn't a good chance of adding it to the roadmap for 21.04.

I agree that this would be an excellent addition to a future roadmap, though. :-)

For now, I'm adding the canonical-bootstrack tag and reducing priority to Medium. This accurately reflects it's place on the priority list, but prevents it from getting lost in the shuffle. Please feel free to add this to the Field Feedback spreadsheet so that it gets its chance to shine during the next roadmap derby ...

[Alvaro Uria (aluria)]

One of the charms uses Juju resources to share files that at later used together with a "restore" action. However, for "backup" actions, there is no workaround except if the action itself pushes backups to a remote location (firewalling could affect this solution).

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

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

[Andrea Ieri (aieri)]

Hi, I'm setting this back to new. I think severity should remain Medium as the operational need hasn't changed.