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

Curtis Hovey-Canonical curtis at canonical.com
Fri Oct 31 14:35:46 UTC 2014


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

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.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui



More information about the Juju-dev mailing list