<div dir="ltr">To be clear, I work for EMC, and we are building a backup product for OpenStack (which at this point is very far along). The primary lack is a good means to efficiently extract changed-block information from OpenStack. About a year ago I worked through the entire Nova/Cinder/libvirt/QEMU stack, to see what was possible. The changes to QEMU (which have been in-flight since 2011) looked most promising, but when they would land was unclear. They are starting to land. This is big news. :)<br><br>That is not the end of the problem. Unless the QEMU folk are perfect, there are likely bugs to be found when the code is put into production. (With more exercise, the sooner any problems can be identified and addressed.) OpenStack uses libvirt to talk to QEMU, and libvirt is a fairly thick abstraction. Likely there will want to be adjustments to libvirt. Bypassing Nova and chatting with libvirt directly is a bit suspect (but may be needed). There might be adjustments needed in Nova.<br><br>To offer suggestions...<br><br>Ekko is an <i>opinionated</i> approach to backup. This is not the only way to solve the problem. I happen very much like the approach, but as a <i>specific </i>approach, it probably does not belong in Cinder or Nova. (I believe it was Jay who offered a similar argument about backup more generally.)<div><br>(Keep in mind QEMU is not the only hypervisor supported by Nova, if the majority of use. Would you want to attempt a design that works for all hypervisors? I would not!  ...at least at this point. Also, last I checked the Cinder folk were a bit hung up on replication, as finding common abstractions across storage was not easy. This problem looks similar.)<br><br>While wary of bypassing Nova/Cinder, my suggestion would to be rude in the beginning, with every intent of becoming civil in the end.<br><br>Start by talking to libvirt directly. (The was a bypass mechanism in libvirt that looked like it might be sufficient.) Break QEMU early, and get it fixed. :)<br><br>When QEMU usage is working, talk to the libvirt folk about <i>proven</i> needs, and what is needed to become civil.<br><br>When libvirt is updated (or not), talk to Nova folk about <i>proven</i> needs, and what is needed to become civil. (Perhaps simply awareness, or a small set of primitives.)<br><br>It might take quite a while for the latest QEMU and libvirt to ripple through into OpenStack distributions. Getting any fixes into QEMU early (or addressing discovered gaps in needed function) seems like a good thing.</div><div><br></div><div>All the above is a sufficiently ambitious project, just by itself. To my mind, that justifies Ekko as a unique, focused project.</div><div><br></div><div><br><br> </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 4:28 PM, Sam Yaple <span dir="ltr"><<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Feb 1, 2016 at 10:32 PM, Fausto Marzi <span dir="ltr"><<a href="mailto:fausto.marzi@gmail.com" target="_blank">fausto.marzi@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Preston,<span class=""><br>Thank you. You saw Fabrizio in Vancouver, I'm Fausto, but it's allright, : P<br><br>The challenge is interesting. If we want to build a dedicated backup API service (which is always what we wanted to do), probably we need to:<br><br><ul><li>Place out of Nova and Cinder the backup features, as it wouldn't make much sense to me to have a Backup service and also have backups managed independently by Nova and Cinder.</li></ul><br>That said, I'm not a big fan of the following:<br><ul><li>Interacting with the hypervisors and the volumes directly without passing through the Nova and Cinder API.</li></ul></span></div></div></div></blockquote><div>Passing through the api will be a huge issue for extracting data due to the sheer volume of data needed (TB through the api is going to kill everything!) </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><ul><li>Adding any additional workload on the compute nodes or block storage nodes.</li><li>Computing incremental, compression, encryption is expensive. Have many simultaneous process doing that may lead  to bad behaviours on core services.<br></li></ul></div></div></div></blockquote></span><div>These are valid concerns, but the alternative is still shipping the raw data elsewhere to do this work, and that has its own issue in terms of bandwidth.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br>My (flexible) thoughts are:<span style="font-size:12.8px"><span><br></span></span><ul><li><span style="font-size:12.8px"><span>The feature is </span></span>needed and is brilliant.</li><li>We should probably implement the newest feature provided by the hypervisor in Nova and export them from the Nova API.</li><li>Create a plugin that is integrated with Freezer to leverage that new features.</li><li>Same apply for Cinder.</li><li>The VMs and Volumes backup feature is already available by Nova, Cinder and Freezer. It needs to be improved for sure a lot, but do we need to create a new project for a feature that needs to be improved, rather than work with the existing Teams?</li></ul></div></div></div></blockquote></span><div>I disagree with this statement strongly as I have stated before. Nova has snapshots. Cinder has snapshots (though they do say cinder-backup). Freezer wraps Nova and Cinder. Snapshots are not backups. They are certainly not _incremental_ backups. They can have neither compression, nor encryption. With this in mind, Freezer does not have this "feature" at all. Its not that it needs improvement, it simply does not exist in Freezer. So a separate project dedicated to that one goal is not unreasonable. The real question is whether it is practical to merge Freezer and Ekko, and this is the question Ekko and the Freezer team are attempting to answer.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><ul><li>No one wants to block others, Sam proposed solution is indeed remarkable, but this is OpenStack, we work in Teams, why we cannot do that and be less fragmented.<br></li></ul><br></div>Thanks,<br></div><div>Fausto<br></div><div><div><div><div><br></div></div></div></div></div></blockquote><div><br></div></span><span class="HOEnZb"><font color="#888888"><div>Sam Yaple </div></font></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>