<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><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,<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></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><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><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><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><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><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 class="h5"><div><div><br></div></div></div></div></div></blockquote><div><br></div><div>Sam Yaple </div></div><br></div></div>