[openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

Sam Yaple samuel at yaple.net
Tue Jan 26 17:03:14 UTC 2016

Didn't hit the mailing list with the last reply. Forwarding to a wider
audience than just Dean
---------- Forwarded message ----------
From: "Sam Yaple" <samuel at yaple.net>
Date: Jan 26, 2016 12:00 PM
Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup
for OpenStack
To: "Dean Troyer" <dtroyer at gmail.com>

On Jan 26, 2016 11:42 AM, "Dean Troyer" <dtroyer at gmail.com> wrote:
> On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple <samuel at yaple.net> wrote:
>> On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>>> My personal request is that the two contributor communities do
everything in their power to ensure that the REST API endpoints are not
overlapping. The last thing we need is to have two APIs for performing
backups that are virtually identical to each other.
>> The way I see this situation is the same as asking Ekko to integrate
with cinder-backup because they perform backups that are "virtually
identical" to each other. They aren't actually related at all, other than
perhaps an API
> But you see this is exactly where they are directly related to everyone
who is not a developer of the back-end services.  Everything that wants to
do a volume backup (users, other services, etc) should not have multiple
choices to perform that backup, irregardless of how that action is

You skipped over the important part. "Actual implementation and end results
are wildly different." They are not the same even if the API call is named
similar, as I originally stated.

> Perhaps this is a problem whose time has come to address?

Absolutely! I would love to not have to worry about building and
maintaining an API. That said, Ekko isn't here to solve that issue.

> I would hate to see us keep duplicating user-facing stuff for the sake of
back-end developer convenience

I agree about not duplicating user-facing things. But it is a bit more than
"back-end developer convenience". I am both an operator and a developer, so
I can speak from both of those points of view when I say I do not want to
be forced to deploy services that I won't use for a feature unrelated to
them. For sale of example, requiring Ceilometer to use Cinder would be
awful. Those wanting to use Ekko may have no interest in using Freezer and
vice versa. Forcing unrelated processes and services for the sake of one
API is not something I agree with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160126/6c7f5c9b/attachment.html>

More information about the OpenStack-dev mailing list