Open Stack

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 at 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 at 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 at gmail.com>
> Cc:
>
>
> On Jan 26, 2016 11:42 AM, "Dean Troyer" <dtroyer at gmail.com> wrote:
> >
> > 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.
>
> 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160126/f4d868a2/attachment.html>