<div dir="ltr"><span class=""><p><span lang="EN-US"><span>Hi Sam,</span></span></p><p><span lang="EN-US"><span>After our conversation, I have few questions and consideration about Ekko, mainly on how it works et similar. Also to make available to the community our discussions:<br></span></span></p><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">In
understand you are placing a backup-agent on the compute node and execute
actions interacting directly with the hypervisor. I’m thinking that while Ekko
execute this actions, the Nova service have no visibility whatsoever of this. I
do not think is a good idea to execute actions directly on the hypervisor without
interacting with the Nova API.</span><span lang="EN-US"> </span>
</p></span><span class=""><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">On
your assumptions, you said that Nova snapshots creation generate a VM downtime.
I don’t think the assumption is correct, at least in Kilo, Liberty and Mitaka.
The only downtime you may have related to the snapshot, is when you merge back
the snapshot to the original root image, and this is not our case here.</span></p>
</span><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">How
the restore would work? If you do a restore of the VM and the record of
that VM instance is not available in the Nova DB (i.e. restoring a VM on
a newly
installed Openstack cloud</span>, or in another region, or after a vm has beed destroyed)<span lang="EN-US">what would happen? How do you manage the consistency
of the data between Nova DB and VM status</span></p>
<p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">If
you execute a backup of the VM image file without executing a backup of the related VM metadata information (in the shortest time frame as possible) there are chances
the backup can be inconsistent. <br></span></p><p>- How the restore would happen if on that moment Keystone or Swift is not available?<br></p><p><span lang="EN-US"></span></p><span class=""><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">Does
the backup that Ekko execute, generates bootable image? If not, the image is
not usable and the restore process will take longer to execute the steps to
make the image bootable.</span><span lang="EN-US"> </span>
</p></span><span class=""><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US"><span> </span>I do not see any advantage in Ekko over using Nova
API to snapshot -> Generate an image -> upload to Glance -> upload to
Swift.</span></p>
<p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">The
Ekko approach is limited to Nova, KVM QEMU, having a qemu-agent running on the
VM. I think the scope is probably a bit limited. This is more a feature than a
tool itself, but the problem is being solved I think more efficiently already.</span></p>
</span><p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">By
executing all the actions related to backup (i.e. compression, incremental computation,
upload, I/O and segmented upload to Swift) Ekko is adding a significant load to
the Compute Nodes.</span> All the work is done on the hypervisor and not taken into account by ceilometer (or similar), so for example not billable.<span lang="EN-US"><b> </b>I do not think this is a good idea as distributing the load
over multiple components helps OpenStack to scale and by leveraging the existing API you integrated better with existing tools.<br></span></p>
<p><span lang="EN-US"><span>-<span style="font:7pt "Times New Roman"">
</span></span></span><span lang="EN-US">There’s
no documentation whatsoever provided with Ekko. I </span>had to read the source code, have conversations directly with you and invest significant time on it<span lang="EN-US"><font color="#0000ff">.</font> I think
provide some documentation is helpful, as the doc link in the openstack/ekko
repo return 404 Not Found.</span></p><p><span lang="EN-US"></span></p><div class="gmail_extra">Please let me know what your thoughts are on this.<br><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">Fausto<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 1:55 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 Wed, Jan 27, 2016 at 7:06 PM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW, the current governance model does not prevent competition. That's not to<br>
be understood as we encourage it but rather than there could be services with<br>
some level of overlap that are still worth being separate.<br>
<br>
What Jay is referring to is that regardless the projects do similar things, the<br>
same or totally different things, we should strive to have different APIs. The<br>
API shouldn't overlap in terms of endpoints and the way they are exposed.<br>
<br>
With all that said, I'd like to encourage collaboration over competition and I'm<br>
sure both teams will find a way to make this work.<br>
<br>
Cheers,<br>
Flavio</blockquote><div><br></div></span><div>And to come full circle on this thread, I will point out once again there is no competition between Ekko and Freezer at this time. Freezer is file-level backup where Ekko is block-level backup. Anyone familiar with backups knows these are drastically different types of backups. Those using block-level backups typically won't be using file-level backups and vice-versa. That said, even if there is no convergence of Freezer and Ekko they can still live side-by-side without any conflict at all.</div><div><br></div><div>As of now, Ekko and Freezer teams have started a dialogue and we will continue to collaborate rather than compete in every way that is reasonable for both projects.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Sam Yaple</div></font></span></div></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></div>