On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple <sam...@yaple.net> wrote: > On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypi...@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 dtro...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
