<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 1, 2016 at 8:23 PM, Preston L. Bannister <span dir="ltr"><<a href="mailto:preston@bannister.us" target="_blank">preston@bannister.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Fausto,<br><br>To be clear, I am not in any way critical of Freezer and the folk putting in work. (Please, I want to be <i>entirely</i> clear on this point! Also, saw your presentation in Vancouver.)<br><br>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.) <br><br>I do not see these as competing projects, and more as cooperative. The Ekko work should be able to plug into Freezer, cleanly. <br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> <br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Aspects of the problem, as I see:<div><ol><li>Extracting efficient instance backups from OpenStack (via new QEMU function).</li><li>Storing backups in efficient form (general implementation, and vendor-specific supersets).<br></li><li>Offering an OpenStack backup-service API, with core and vendor-specific extensions.</li></ol><div><br></div><div>Vendors (like my employer, EMC) might be somewhat opinionated about (2), and for reason. :)<br></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>The huge missing piece is (1), and a focused project seems to make a lot of sense.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Sam Yaple</div></div></div></div>