<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 26, 2016 at 9:28 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div><div><div dir="ltr">On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br></div></div></div></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote><div><br></div></span><div>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 </div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>call that says 'backup'. Actual implementation and end results are wildly different. So my question would be, how would you go about solving that situation? I could absolutely get on board with sharing an API and even scheduler, but Ekko and Freezer are two distinct projects solving different issues with different infrastructure requirements and I am not aware of anyway to share APIs between projects other than merging the projects.</div></div></div></div></blockquote><div><br></div><div>Perhaps this is a problem whose time has come to address?</div><div><br></div><div><br></div></div>I want to expand a bit on Jay's overlapping API comment.  It is at the beginning of a project like this that we have the one and only chance of getting the API right without having to worry about backward compatibility.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the field today we have a large number of consumers of our APIs (Horizon, our own client libs, the Python SDK, jclouds, libcloud, gophercloud, and the list goes on) not to mention those who are writing their own for various reasons.  Making sense of these across projects gets more important with every new project that intends to become 'one of us'.<br clear="all"></div><div><br></div><div class="gmail_extra">We (OpenStack community, from day 2) have always considered back-end implementation as one of the major differentaiting factors in our projects.  Our API consumers frankly don't care about that.  We present a lot of endpoints and APIs.  But for those areas where there may be some overlap, or for even competing implementations, we should be working from the beginning to make these APIs look sensible to those who consume them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It just so happens that the API working group is addressing some of these things related to the API structure and striving for consistency across OpenStack.  However, that is more of a matter of form and structure, not of implementation and back-end structure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I would hate to see us keep duplicating user-facing stuff for the sake of back-end developer convenience.</div><div class="gmail_extra"><br></div><div class="gmail_extra">dt</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>