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

<p dir="ltr">As a summary, I don't trust in big-bangs in Nova and prefer to do small iterations with the current state.</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>
<p dir="ltr">> > Unfortunately, I'm on PTO till Tuesday, and Paul Murray this week as<br>
> > well. So I propose to delay the discussion by these days as that's not<br>
> > impacted by FPF.<br>
> ><br>
> > In the meantime, I created a patch for discussing a workaround [1] for<br>
> > Juno until we correctly figure out how to fix that issue, as it deserves<br>
> > a spec.<br>
> ><br>
> >> Time is running out for Juno.<br>
> >><br>
> ><br>
> > Indeed, I'm mostly concerned by the example exception spec that Nikola<br>
> > mentioned [2] (isolate-scheduler-db) as it still needs a second +2 while<br>
> > FPF is in 1 week...<br>
> > I'm planning to deliver an alternative implementation without ERT wrt<br>
> > this discussion.<br>
> ><br>
><br>
> Ripping it out will make it more difficult for the Gantt team to go<br>
> ahead with the current plan for the split - yes, but maybe that actually<br>
> means you might want to re-visit some of your decision (did not follow<br>
> all of it, so don't want to comment in depth at this point, but throwing<br>
> it out there)?<br>
><br>
> N.</p>
<p dir="ltr">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.</p>
<p dir="ltr">I'm rally open to discussion in the spec itself, as I really like hearing other voices.</p>
<p dir="ltr">><br>
> > -Sylvain<br>
> ><br>
> > [1] <a href="https://review.openstack.org/#/c/113936/">https://review.openstack.org/#/c/113936/</a><br>
> ><br>
> > [2] <a href="https://review.openstack.org/#/c/89893">https://review.openstack.org/#/c/89893</a><br>
> ><br>
> >> Thanks,<br>
> >> Michael<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>