Open Stack

Le 15 août 2014 08:16, "Nikola Đipanov" <ndipanov at redhat.com> a écrit :
>
> On 08/14/2014 10:25 PM, Sylvain Bauza wrote:
> > Hi mikal,
> >
> > Le 14 août 2014 01:49, "Michael Still" <mikal at stillhq.com
> > <mailto:mikal at stillhq.com>> a écrit :
> >>
> >> So, there's been a lot of email in the last few days and I feel I am
> >> not keeping up.
> >>
> >> Sylvain, can you summarise for me what the plan is here? Can we roll
> >> forward or do we need to revert?
> >
> > Well, as we agreed with Nikola, the problem is not with ERT but RT, as
> > the request data needs to be passed when claiming a resource.
> >
> > I'm proposing to keep ERT and only consider plugins that are not needing
> > request_spec when claiming, but here there is no agreement yet.
> >
>
> Yes - we could do this, I still see no benefit in this.
>
> FWIW - Jay Pipes made a comment that highlights much of the same issues
> I did in this thread even before I started it, on the patch itself
> (scroll down).
>
> https://review.openstack.org/#/c/109643/
>
> It's easy to miss since it was added post merge.
>

As said previously, I'm not saying that the current interface would not
have to change because of some issues. My personal concern is that I just
don't want to see technical debt blocking all temptatives to move forward
and treat this technical debt more easily because of a separate project
with new velocity.

As a summary, I don't trust in big-bangs in Nova and prefer to do small
iterations with the current state.

So that's why I'm pro a negociative approach. Take the filters and the job
we do by removing direct access to DB : as anyone can propose a patch
breaking that (and you know how it's easy to propose a filter and how many
people are doing that at the moment...), that's reviewers duty - and me in
particular - to say their voice in order to make sure it's not going to be
merged.

Here, same idea. That's not a REST API that anyone can consume, new plugins
still need to be merged if they want to go upstream.

> > Unfortunately, I'm on PTO till Tuesday, and Paul Murray this week as
> > well. So I propose to delay the discussion by these days as that's not
> > impacted by FPF.
> >
> > In the meantime, I created a patch for discussing a workaround [1] for
> > Juno until we correctly figure out how to fix that issue, as it deserves
> > a spec.
> >
> >> Time is running out for Juno.
> >>
> >
> > Indeed, I'm mostly concerned by the example exception spec that Nikola
> > mentioned [2] (isolate-scheduler-db) as it still needs a second +2 while
> > FPF is in 1 week...
> > I'm planning to deliver an alternative implementation without ERT wrt
> > this discussion.
> >
>
> Ripping it out will make it more difficult for the Gantt team to go
> ahead with the current plan for the split - yes, but maybe that actually
> means you might want to re-visit some of your decision (did not follow
> all of it, so don't want to comment in depth at this point, but throwing
> it out there)?
>
> N.

Well, you hit a good point : what alternative if so ? This spec had many
proposals as many solutions can be found but we decided to go with ERT
because of its good integration with the existing RT.

I'm rally open to discussion in the spec itself, as I really like hearing
other voices.

>
> > -Sylvain
> >
> > [1] https://review.openstack.org/#/c/113936/
> >
> > [2] https://review.openstack.org/#/c/89893
> >
> >> Thanks,
> >> Michael
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140815/db7e7e8f/attachment.html>