Open Stack

On 01/26/2016 03:28 PM, Sam Yaple wrote:
> On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
>     On 01/26/2016 02:47 AM, Sam Yaple wrote:
>
>         Hello Fausto,
>
>         I am happy to have a conversation about this with you and the
>         Freezer
>         team. I have a feeling the current direction of Ekko will add many
>         components that will not be needed for Freezer and vice-versa.
>         Nevertheless, I am all about community!
>
>
>     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.

No. You have entirely misunderstood my point.

 > They aren't actually related at all, other
> than perhaps an API 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.

I am not suggesting you "share an API" at all. I am requesting that if 
you have a RESTful API planned for your "backup", then you do not use 
the same RESTful API resource endpoint names that Freezer does. Because 
if you do, then users of the OpenStack APIs will have two APIs that use 
identical resource endpoints for entirely different things. So the 
request is to not use Freezer's resource endpoints, which have /backups 
as its primary resource endpoint.

I don't like the fact that Freezer's resource endpoint is /backups, 
since the OpenStack Volume API has a /{tenant_id}/backups resource 
endpoint, but I really, *really* do not want to see a set of OpenStack 
APIs one of which has /{tenant_id}/backups as a resource endpoint, 
another which has /backups as a top-level resource, and still another 
which has /backups as a top-level resource.

It makes for a crappy user experience. Crappier than the crappy user 
experience that OpenStack API users already have because we have done a 
crappy job shepherding projects in order to make sure there isn't 
overlap between their APIs (yes, Ceilometer and Monasca, I'm looking 
directly at you).

Thanks,
-jay