Open Stack

Hi Sam,

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:

-          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.

-          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.

-          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, or in another region,
or after a vm has beed destroyed)what would happen? How do you manage the
consistency of the data between Nova DB and VM status

-          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.

- How the restore would happen if on that moment Keystone or Swift is not
available?

-          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.

-           I do not see any advantage in Ekko over using Nova API to
snapshot -> Generate an image -> upload to Glance -> upload to Swift.

-          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.

-          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. All the work
is done on the hypervisor and not taken into account by ceilometer (or
similar), so for example not billable. 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.

-          There’s no documentation whatsoever provided with Ekko. I had to
read the source code, have conversations directly with you and invest
significant time on it. I think provide some documentation is helpful, as
the doc link in the openstack/ekko repo return 404 Not Found.

Please let me know what your thoughts are on this.

Thanks,
Fausto


On Wed, Jan 27, 2016 at 1:55 PM, Sam Yaple <samuel at yaple.net> wrote:

> On Wed, Jan 27, 2016 at 7:06 PM, Flavio Percoco <flavio at redhat.com> wrote:
>>
>> FWIW, the current governance model does not prevent competition. That's
>> not to
>> be understood as we encourage it but rather than there could be services
>> with
>> some level of overlap that are still worth being separate.
>>
>> What Jay is referring to is that regardless the projects do similar
>> things, the
>> same or totally different things, we should strive to have different
>> APIs. The
>> API shouldn't overlap in terms of endpoints and the way they are exposed.
>>
>> With all that said, I'd like to encourage collaboration over competition
>> and I'm
>> sure both teams will find a way to make this work.
>>
>> Cheers,
>> Flavio
>
>
> 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.
>
> 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.
>
> Sam Yaple
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160127/73a3ac72/attachment.html>