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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
