settingsLogin | Registersettings

[openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

0 votes

Dear community,

We would like to introduce you to a new community-driven OpenStack project
called Ekko.

The aim of Ekko is to provide incremental block-level backup and restore of
Nova instances. We see backups as a key area that is missing in OpenStack.
One issue that has previously prevented backups in OpenStack is the
scalability of the storage backend. Object-storage is the answer to this
scalability problem, but with block-based backups you often see large files
that require POSIX operations to perform retention and deletions. These
operations are not able to be performed in the traditional way in object
storage, which has prevented leveraging object-storage to its full
potential. With Ekko we can solve this issue allowing us to use storage
that can scale with OpenStack.

Based on previous projects [1] and research that has been progressing for
the past 2 years or so, Ekko is being completely written from scratch by
the community, incorporating these learnings. This research combined with a
new feature available in QEMU 2.4 [2] will allow us to bring incremental
block-based backups to OpenStack.

The project is in it's beginning stages, however, we already have active
developers submitting code and collaborating via IRC and code review [3].
We welcome thoughts, questions, and feedback. You can join us on

openstack-ekko, and be sure to keep an eye out for our talk at the summit

to learn more.

Best Regards,
The Ekko Team

[1] https://github.com/SamYaple/osdk
[2] http://wiki.qemu.org/Features/IncrementalBackup
[3] https://review.openstack.org/#/q/project:openstack/ekko


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jan 22, 2016 in openstack-dev by Sam_Yaple (3,560 points)   3 3
retagged Feb 4, 2016 by admin

59 Responses

0 votes

Sam Yaple wrote:
We would like to introduce you to a new community-driven OpenStack
project called Ekko.

The aim of Ekko is to provide incremental block-level backup and restore
of Nova instances. We see backups as a key area that is missing in
OpenStack. One issue that has previously prevented backups in OpenStack
is the scalability of the storage backend. Object-storage is the answer
to this scalability problem, but with block-based backups you often see
large files that require POSIX operations to perform retention and
deletions. These operations are not able to be performed in the
traditional way in object storage, which has prevented leveraging
object-storage to its full potential. With Ekko we can solve this issue
allowing us to use storage that can scale with OpenStack.

Hi!

How does Ekko compare to / differ from Freezer, which is an official
OpenStack project targeted to the same problem space ? I suspect this is
more low-level ? Is there some potential for convergence between the two
projects ?

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 25, 2016 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On Mon, Jan 25, 2016 at 8:45 AM, Thierry Carrez thierry@openstack.org
wrote:

Sam Yaple wrote:

We would like to introduce you to a new community-driven OpenStack
project called Ekko.

The aim of Ekko is to provide incremental block-level backup and restore
of Nova instances. We see backups as a key area that is missing in
OpenStack. One issue that has previously prevented backups in OpenStack
is the scalability of the storage backend. Object-storage is the answer
to this scalability problem, but with block-based backups you often see
large files that require POSIX operations to perform retention and
deletions. These operations are not able to be performed in the
traditional way in object storage, which has prevented leveraging
object-storage to its full potential. With Ekko we can solve this issue
allowing us to use storage that can scale with OpenStack.

Hi!

How does Ekko compare to / differ from Freezer, which is an official
OpenStack project targeted to the same problem space ? I suspect this is
more low-level ? Is there some potential for convergence between the two
projects ?

Hello Thierry,

These are good questions. The biggest difference you already caught onto,
Ekko is more low-level. Freezer is targeted at the filesystem and specific
applications (like databases) directly.

There are only two places with overlapping goals that I know of*. The first
is backup of a Cinder volume which is a future goal of Ekko and something
Freezer can currently do for LVM backed Cinder. The second is backup of a
nova instance. This isn't something freezer does directly, instead it
leverages nova-snapshot which is very disruptive to the instance and will
cause downtime for said instance. The current pursuit of Ekko is live
incremental block-level backup of an nova instance and in that regard there
is no overlap with Freezer or any other project for that matter.

To answer the question of convergence between Ekko and Freezer, I would say
it's possible. That being said both projects are addressing different
problems in different ways. As discussed above, there is little overlap
between the two projects and the areas where there is overlap of goals have
drastically different implementations. I could put together a list of Ekko
vs Freezer, but I think that would be comparing apples to oranges. To state
this in terms of compatibility, Ekko and Freezer can run side-by-side
without interfering with each other in anyway.

*Disclaimer: I am no expert on Freezer, I may be wrong in some statements
and am open to correction.

Sam Yaple

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 25, 2016 by Sam_Yaple (3,560 points)   3 3
0 votes

Hi Sam,
My opinion would be to converge, so to have Ekko features exported from the freezer-api and horizon web interface. Also the freezer-scheduler can be integrated, that would enable Ekko to execute backup syncronized over multiple nodes.

By all mean, this does not mean you have to, it's just how I feel about it.

We are totally open, so please let us know if there's any interest from your side.

Thanks,
Fausto

Sent from my iPhone

On 25 Jan 2016, at 08:58, Sam Yaple samuel@yaple.net wrote:

On Mon, Jan 25, 2016 at 8:45 AM, Thierry Carrez thierry@openstack.org wrote:
Sam Yaple wrote:

We would like to introduce you to a new community-driven OpenStack
project called Ekko.

The aim of Ekko is to provide incremental block-level backup and restore
of Nova instances. We see backups as a key area that is missing in
OpenStack. One issue that has previously prevented backups in OpenStack
is the scalability of the storage backend. Object-storage is the answer
to this scalability problem, but with block-based backups you often see
large files that require POSIX operations to perform retention and
deletions. These operations are not able to be performed in the
traditional way in object storage, which has prevented leveraging
object-storage to its full potential. With Ekko we can solve this issue
allowing us to use storage that can scale with OpenStack.

Hi!

How does Ekko compare to / differ from Freezer, which is an official OpenStack project targeted to the same problem space ? I suspect this is more low-level ? Is there some potential for convergence between the two projects ?

Hello Thierry,

These are good questions. The biggest difference you already caught onto, Ekko is more low-level. Freezer is targeted at the filesystem and specific applications (like databases) directly.

There are only two places with overlapping goals that I know of*. The first is backup of a Cinder volume which is a future goal of Ekko and something Freezer can currently do for LVM backed Cinder. The second is backup of a nova instance. This isn't something freezer does directly, instead it leverages nova-snapshot which is very disruptive to the instance and will cause downtime for said instance. The current pursuit of Ekko is live incremental block-level backup of an nova instance and in that regard there is no overlap with Freezer or any other project for that matter.

To answer the question of convergence between Ekko and Freezer, I would say it's possible. That being said both projects are addressing different problems in different ways. As discussed above, there is little overlap between the two projects and the areas where there is overlap of goals have drastically different implementations. I could put together a list of Ekko vs Freezer, but I think that would be comparing apples to oranges. To state this in terms of compatibility, Ekko and Freezer can run side-by-side without interfering with each other in anyway.

*Disclaimer: I am no expert on Freezer, I may be wrong in some statements and am open to correction.

Sam Yaple

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Fausto_Marzi (900 points)  
0 votes

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!

Sam Yaple

On Tue, Jan 26, 2016 at 2:20 AM, Fausto Marzi fausto.marzi@gmail.com
wrote:

Hi Sam,
My opinion would be to converge, so to have Ekko features exported from
the freezer-api and horizon web interface. Also the freezer-scheduler can
be integrated, that would enable Ekko to execute backup syncronized over
multiple nodes.

By all mean, this does not mean you have to, it's just how I feel about it.

We are totally open, so please let us know if there's any interest from
your side.

Thanks,
Fausto

Sent from my iPhone

On 25 Jan 2016, at 08:58, Sam Yaple samuel@yaple.net wrote:

On Mon, Jan 25, 2016 at 8:45 AM, Thierry Carrez thierry@openstack.org
wrote:

Sam Yaple wrote:

We would like to introduce you to a new community-driven OpenStack
project called Ekko.

The aim of Ekko is to provide incremental block-level backup and restore
of Nova instances. We see backups as a key area that is missing in
OpenStack. One issue that has previously prevented backups in OpenStack
is the scalability of the storage backend. Object-storage is the answer
to this scalability problem, but with block-based backups you often see
large files that require POSIX operations to perform retention and
deletions. These operations are not able to be performed in the
traditional way in object storage, which has prevented leveraging
object-storage to its full potential. With Ekko we can solve this issue
allowing us to use storage that can scale with OpenStack.

Hi!

How does Ekko compare to / differ from Freezer, which is an official
OpenStack project targeted to the same problem space ? I suspect this is
more low-level ? Is there some potential for convergence between the two
projects ?

Hello Thierry,

These are good questions. The biggest difference you already caught onto,
Ekko is more low-level. Freezer is targeted at the filesystem and specific
applications (like databases) directly.

There are only two places with overlapping goals that I know of*. The
first is backup of a Cinder volume which is a future goal of Ekko and
something Freezer can currently do for LVM backed Cinder. The second is
backup of a nova instance. This isn't something freezer does directly,
instead it leverages nova-snapshot which is very disruptive to the instance
and will cause downtime for said instance. The current pursuit of Ekko is
live incremental block-level backup of an nova instance and in that
regard there is no overlap with Freezer or any other project for that
matter.

To answer the question of convergence between Ekko and Freezer, I would
say it's possible. That being said both projects are addressing different
problems in different ways. As discussed above, there is little overlap
between the two projects and the areas where there is overlap of goals have
drastically different implementations. I could put together a list of Ekko
vs Freezer, but I think that would be comparing apples to oranges. To state
this in terms of compatibility, Ekko and Freezer can run side-by-side
without interfering with each other in anyway.

*Disclaimer: I am no expert on Freezer, I may be wrong in some statements
and am open to correction.

Sam Yaple

--

Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Sam_Yaple (3,560 points)   3 3
0 votes

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.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Jay_Pipes (59,760 points)   3 10 14
0 votes

On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes jaypipes@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. 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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Sam_Yaple (3,560 points)   3 3
0 votes

On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple samuel@yaple.net wrote:

On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes jaypipes@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@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Dean_Troyer (13,100 points)   1 3 3
0 votes

Didn't hit the mailing list with the last reply. Forwarding to a wider
audience than just Dean
---------- Forwarded message ----------
From: "Sam Yaple" samuel@yaple.net
Date: Jan 26, 2016 12:00 PM
Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup
for OpenStack
To: "Dean Troyer" dtroyer@gmail.com
Cc:

On Jan 26, 2016 11:42 AM, "Dean Troyer" dtroyer@gmail.com wrote:

On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple samuel@yaple.net wrote:

On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes jaypipes@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.

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.

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

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.

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

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Sam_Yaple (3,560 points)   3 3
0 votes

Hi Jay, Dean,
totally agree, with Sam, we'll make sure there will not be any overlap.

Sam,
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?

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.

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.

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
: )

Sounds good?

I'll set up a public meeting next week to discuss this.

Many thanks,
Fausto

On Tue, Jan 26, 2016 at 11:03 AM, Sam Yaple samuel@yaple.net wrote:

Didn't hit the mailing list with the last reply. Forwarding to a wider
audience than just Dean
---------- Forwarded message ----------
From: "Sam Yaple" samuel@yaple.net
Date: Jan 26, 2016 12:00 PM
Subject: Re: [openstack-dev] Announcing Ekko -- Scalable block-based
backup for OpenStack
To: "Dean Troyer" dtroyer@gmail.com
Cc:

On Jan 26, 2016 11:42 AM, "Dean Troyer" dtroyer@gmail.com wrote:

On Tue, Jan 26, 2016 at 9:28 AM, Sam Yaple samuel@yaple.net wrote:

On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes jaypipes@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.

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.

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

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.

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

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Fausto_Marzi (900 points)  
0 votes

On 01/26/2016 03:28 PM, Sam Yaple wrote:
On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypipes@gmail.com
jaypipes@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 /{tenantid}/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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2016 by Jay_Pipes (59,760 points)   3 10 14
...