Actions should accept files as a parameter
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Medium
|
Eric Claude Jones |
Bug Description
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-
$ juju show-action-output b46d5d6f-
results:
copy:
cmd: juju scp etcd/0:
.
snapshot:
path: /home/ubuntu/
sha256: 1dea04627812397
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=
action-set foo=bar
```
```
$ juju run-action etcd/0
Action queued with id: b46d5d6f-
$ juju show-action-output b46d5d6f-
results:
foo: bar
files:
snapshot:
file: etcd-snapshot-
sha256: 1dea04627812397
size: 68K
status: completed
```
At this point in time the user could download an attachment with a new juju command (either get-action-
```
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=
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.
-rw-rw-r-- 1 marco marco 0b etcd-snapshot.txt
$ juju run-action etcd/0 restore snapshot=
Action queued with id: b46d5d6f-
$ juju run-action etcd/0 restore snapshot=
Action failed: snapshot file does not exist
$ juju run-action etcd/0 restore snapshot=
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/
```
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.
tags: | added: actions |
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
tags: | added: talisman |
Changed in juju: | |
assignee: | nobody → Eric Claude Jones (ecjones) |
importance: | Wishlist → High |
milestone: | none → 2.3-alpha1 |
Changed in juju: | |
milestone: | 2.3-beta1 → 2.3-beta2 |
Changed in juju: | |
milestone: | 2.3-beta2 → none |
Changed in juju: | |
importance: | Low → Medium |
status: | New → Triaged |
+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.