Open Stack

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


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

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


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.

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

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.

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.

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

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160126/0accd731/attachment.html>