<div dir="ltr"><div><div><div><div>Hi Jay, Dean,<br></div>totally agree, with Sam, we'll make sure there will not be any overlap.<br><br></div>Sam,<br></div>Thanks
 for your openness. I'd like to have a conversation about it. When you 
say "current direction of Ekko will add many components" do you have any
 reference, plan or road map where we can see that direction and 
components more in detail?<br><br></div><div>Very soon we'll starting 
working also on the block based incremental, that will be overlapping...
 if Ekko would fit and we do not have to re implement it, that'd be 
fantastic, and not overlapping =). I see many points we can converge.<br><br></div><div>From
 our perspective, we try to focus more on what can be converged rather 
then what cannot. Converging is something that allow us to move forward 
faster, delivering something better to the Community, that's the only motivation.<br></div><div><br></div><div>Let's talk on what we can do, I'm totally confident we'll find a way to do something useful for everybody : ), beside we matured some experience dealing positively with the OS community, that will benefit you, believe me : )<br></div><div><br></div><div>Sounds good?<br><br></div><div>I'll set up a public meeting next week to discuss this.<br><br></div><div>Many thanks,<br></div><div>Fausto<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 11:03 AM, 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"><p dir="ltr">Didn't hit the mailing list with the last reply. Forwarding to a wider audience than just Dean<span class=""><br>
---------- Forwarded message ----------<br>
From: "Sam Yaple" <<a href="mailto:samuel@yaple.net" target="_blank">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></span>
To: "Dean Troyer" <<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>><br>
Cc: </p>
<blockquote><span class=""><p dir="ltr"><br>
On Jan 26, 2016 11:42 AM, "Dean Troyer" <<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>> wrote:<br>
><br>
> On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple <<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>> wrote:<br>
>><br>
>> On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">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>
</span><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><span class="">
<p dir="ltr">> Perhaps this is a problem whose time has come to address?</p>
</span><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><span class="">
<p dir="ltr">> I would hate to see us keep duplicating user-facing stuff for the sake of back-end developer convenience</p>
</span><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>
<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>