Open Stack

On Mon, Feb 1, 2016 at 8:23 PM, Preston L. Bannister <preston at bannister.us>
wrote:

> Hi Fausto,
>
> To be clear, I am not in any way critical of Freezer and the folk putting
> in work. (Please, I want to be *entirely* clear on this point! Also, saw
> your presentation in Vancouver.)
>
> That said, Freezer is a bit of a Swiss-Army-Knife set of combined backup
> functions. Sometimes it is better to focus on a single aspect (or few). The
> new features landing in QEMU present an opportunity. A project focused
> solely on that opportunity, to work through initial set of issues, makes a
> lot of sense to me. (Something like how KVM forked QEMU for a time, to
> build faster x86 emulation.)
>
> I do not see these as competing projects, and more as cooperative. The
> Ekko work should be able to plug into Freezer, cleanly.
>

>From what I see this is certainly a possibly future. Ekko may be able to
complement Freezer by running as a plugin, but just as easily be a
standalone project that is fully compatible with a Freezer without
conflicting in any way. As an operator, I am a fan of only deploying what
is needed and Freezer needs infrastructure to do what it does that isn't
useful to block-based backup purposed by Ekko. That may change as we have
already started talking with the Freezer team and they have this idea of a
plugin-type system that may very well do the trick.


>
Aspects of the problem, as I see:
>
>    1. Extracting efficient instance backups from OpenStack (via new QEMU
>    function).
>    2. Storing backups in efficient form (general implementation, and
>    vendor-specific supersets).
>    3. Offering an OpenStack backup-service API, with core and
>    vendor-specific extensions.
>
>
> Vendors (like my employer, EMC) might be somewhat opinionated about (2),
> and for reason. :)
>

On the note of point (2), its not so much the storage as managing retention
in object storage (essentially a read-only medium). I would argue (2) is
much harder than (1). People have been doing (1) with VMWare for a long
time, and QEMU's steps won't be that different.


> The huge missing piece is (1), and a focused project seems to make a lot
> of sense.
>

And everyone please keep in mind, the only overlap I have seen so far is
the API, and _potentially_ the scheduler. So if a merging is needed, then
it should be fairly simple. None of this has to be decided right now. We
aren't going down a path that can't be reversed, and we likely never will
given how little these two projects overlap in their current forms.

Sam Yaple
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160202/6daf9ff8/attachment.html>