On Tue, Jul 29, 2014 at 6:57 PM, roger peppe <[email protected]> wrote:
> On 29 July 2014 16:50, Eric Snow <[email protected]> wrote: > > 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. > > An HTTP POST request seems about right for a call that > streams a significant amount of data. Is there any particular > reason this has to change? > It's not what we discussed and agreed in vegas; and, crucially, it fails to make previously-made backups available from any state server. We want WS APIs for creating, listing, and deleting backups; and, yes, we want to *download* those backups over HTTP, and the CLI will be creating them, waiting for them to be ready, and then downloading them over HTTP. But a POST to just create-a-backup-and-download-it-and-forget-about-it is not what we want or need. WRT the proposal: Given that we explicitly flagged the POST API as experimental, and we didn't release a client that actually used it, I think we're safe fixing and backporting (although, remember, the 1.18-based backup/restore needs to continue to work -- this lets us handle only *two* mechanisms rather than three, it doesn't let us use just one). But I'm a bit suspicious... would someone please confirm that we don't have *any* released clients that use the POST API? The above is predicated on that assumption. Cheers William
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
