backups create and backups restore defaults clash

[Aaron Bentley]

"backups create" and "backups restore" have two modes:
1. Re-create a state-server from a backup
2. Restore a state-server to a previous state.

The default for "create" is to download a file, so you would expect to supply a file to "restore". But with the default behaviour, "restore" will error, because the file already exists on the server.

These are the pairings that make sense:
- "juju backup", "juju restore -b --file"
- "juju backup --no-download", "juju restore".

It would be nice if one of these defaults could be changed for 2.0

Making "restore -b" the default would also fix most of bug #1536333.

Example failure with restore --file:
2016-01-20 16:03:50 INFO juju.cmd supercommand.go:58 running juju [2.0-alpha1 gc]
2016-01-20 16:03:50 INFO juju.api api.go:267 connecting to API addresses: [52.90.214.92:17070 172.31.14.136:17070]
2016-01-20 16:03:50 INFO juju.api apiclient.go:484 dialing "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:03:50 INFO juju.api apiclient.go:484 dialing "wss://172.31.14.136:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:03:50 INFO juju.api apiclient.go:277 connection established to "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:03:52 INFO juju.api api.go:267 connecting to API addresses: [52.90.214.92:17070 172.31.14.136:17070]
2016-01-20 16:03:52 INFO juju.api apiclient.go:484 dialing "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:03:52 INFO juju.api apiclient.go:484 dialing "wss://172.31.14.136:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:03:52 INFO juju.api apiclient.go:277 connection established to "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:04:45 INFO juju.api api.go:267 connecting to API addresses: [52.90.214.92:17070 172.31.14.136:17070]
2016-01-20 16:04:45 INFO juju.api apiclient.go:484 dialing "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:04:45 INFO juju.api apiclient.go:484 dialing "wss://172.31.14.136:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:04:45 INFO juju.api apiclient.go:277 connection established to "wss://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/api"
2016-01-20 16:04:46 ERROR juju.api.backups restore.go:75 could not exit restoring status: cannot complete restore: <nil>: Restore did not finish succesfuly
2016-01-20 16:04:46 ERROR cmd supercommand.go:448 cannot upload backup file: PUT https://52.90.214.92:17070/environment/b060e4d2-af48-41ac-8c89-6ae9e4bdce3c/backups: while storing backup archive: backup metadata "20160120-160254.b060e4d2-af48-41ac-8c89-6ae9e4bdce3c" already exists
2016-01-20 16:04:46 INFO cmd supercommand.go:454 command finished

[John A Meinel (jameinel)]

I think we are moving to a design where "juju create-backup" creates a file and doesn't save the backup on the controller, and thus "juju restore-backup" should prefer to take the file and not default to using one that is already saved on the controller.

However, I don't think there is anything to be done in the 2.X timeline that wouldn't end up being more of a CLI break than it is really worth.

[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.