backup API in 1.20

William Reade william.reade at canonical.com
Tue Jul 29 17:12:50 UTC 2014


On Tue, Jul 29, 2014 at 6:57 PM, roger peppe <rogpeppe at gmail.com> wrote:

> On 29 July 2014 16:50, Eric Snow <eric.snow at canonical.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140729/6e5ea287/attachment.html>


More information about the Juju-dev mailing list