<p dir="ltr">Didn't hit the mailing list with the last reply. Forwarding to a wider audience than just Dean<br>
---------- Forwarded message ----------<br>
From: "Sam Yaple" <<a href="mailto:samuel@yaple.net">samuel@yaple.net</a>><br>
Date: Jan 26, 2016 12:00 PM<br>
Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack<br>
To: "Dean Troyer" <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>><br>
Cc: </p>
<blockquote><p dir="ltr"><br>
On Jan 26, 2016 11:42 AM, "Dean Troyer" <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br>
><br>
> On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple <<a href="mailto:samuel@yaple.net">samuel@yaple.net</a>> wrote:<br>
>><br>
>> On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>><br>
>> 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<br>
><br>
><br>
> 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 implemented.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Perhaps this is a problem whose time has come to address?</p>
<p dir="ltr">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.</p>
<p dir="ltr">> I would hate to see us keep duplicating user-facing stuff for the sake of back-end developer convenience</p>
<p dir="ltr">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.<br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>