backup API in 1.20
Eric Snow
eric.snow at canonical.com
Tue Jul 29 15:50:58 UTC 2014
The API server side of backup made it into 1.20 (the client-side and
CLI did not). However, the API is exposed via HTTP POST rather than
through websockets RPC. We are correcting this right now. The
question is, are there any objections to removing backup from the
state API in 1.20 (or, less desirably, backporting the
POST->websockets change)?
Proposal
=======
Remove state/backup/ and state/apiserver/backup.go from 1.20.
Alternative
=========
Backport POST->websockets change to 1.20.
Motivation
========
* eliminate POST-base backup API
* juju 1.20 in trusty
Impact
======
The impact on users should be vanishingly small. The client and CLI
sides of backup did not make it into 1.20, and we have not documented
the state API. I expect that there is no one using the backup API
currently. The situation would be more problematic if 1.20 makes it
into trusty; we would have to continue supporting the POST-based
backup API (along with the newer websockets one).
The impact on juju should be positive. We will not need to support
both a POST-based backup API and a websockets-based one. Removing the
backup API will be a much less complicated change than backporting the
websockets-based API.
-eric
More information about the Juju-dev
mailing list