deprecating the juju-backup (and juju-restore) CLI plugin

[Eric Snow]

On Fri, Oct 31, 2014 at 8:35 AM, Curtis Hovey-Canonical
<curtis at canonical.com> wrote:
> On Thu, Oct 30, 2014 at 2:10 PM, Eric Snow <eric.snow at canonical.com> wrote:
>> What would be the best approach for deprecating the old backup plugin?
>>  I was going to simply gut it (it's a bash script) and stick in a
>> deprecation warning message and a call to "juju backups create
>> --download".  However, jam rightly pointed out to me that this may be
>> a sticky situation (as described above).  I'd really like to find a
>> way to eliminate the old backup implementation.  Thoughts?
>
> Look before you leap. Call juju status and check that the version is
> 1.21.+ and use new command, else old command.

Good idea.

> We expect new clients to
> manage old state-servers during transitions. The transition my be long
> if the enterprise is not upgrading their envs. I think we are stuck
> with the old implementation for as long as we support trusty.

Yeah, that's what I figured but hoped wasn't the case.

>
> Users do not know that backup is a bash script...
>     juju backup
> is the command, so we can write an alternate plugin that checks the
> state-server version, then either calls to new command or the old
> script which is renamed, If we rename/change juju-backup.bash, we need
> a simultaneous packaging change.

Since it is transparent to users and otherwise mostly irrelevant, I'll
leave the filename alone and add the conditional operation to the
existing script.

Am I okay with adding a deprecation warning message (to stderr) that
instructs "juju backup" users to use "juju backups create" instead?
I'm not sure what precedent there is for doing so with our CLI.

-eric