On Mon, Feb 1, 2016 at 8:23 PM, Preston L. Bannister <pres...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
