<p dir="ltr">Hi mikal,</p>
<p dir="ltr">Le 14 août 2014 01:49, "Michael Still" <<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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Time is running out for Juno.<br>
></p>
<p dir="ltr">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...<br>
I'm planning to deliver an alternative implementation without ERT wrt this discussion.</p>
<p dir="ltr">-Sylvain</p>
<p dir="ltr">[1] <a href="https://review.openstack.org/#/c/113936/">https://review.openstack.org/#/c/113936/</a></p>
<p dir="ltr">[2] <a href="https://review.openstack.org/#/c/89893">https://review.openstack.org/#/c/89893</a></p>
<p dir="ltr">> Thanks,<br>
> Michael<br>
><br>
> On Thu, Aug 14, 2014 at 3:40 AM, Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>> wrote:<br>
> ><br>
> > Le 13/08/2014 18:40, Brian Elliott a écrit :<br>
> ><br>
> >> On Aug 12, 2014, at 5:21 AM, Nikola Đipanov <<a href="mailto:ndipanov@redhat.com">ndipanov@redhat.com</a>> wrote:<br>
> >><br>
> >>> Hey Nova-istas,<br>
> >>><br>
> >>> While I was hacking on [1] I was considering how to approach the fact<br>
> >>> that we now need to track one more thing (NUMA node utilization) in our<br>
> >>> resources. I went with - "I'll add it to compute nodes table" thinking<br>
> >>> it's a fundamental enough property of a compute host that it deserves to<br>
> >>> be there, although I was considering  Extensible Resource Tracker at one<br>
> >>> point (ERT from now on - see [2]) but looking at the code - it did not<br>
> >>> seem to provide anything I desperately needed, so I went with keeping it<br>
> >>> simple.<br>
> >>><br>
> >>> So fast-forward a few days, and I caught myself solving a problem that I<br>
> >>> kept thinking ERT should have solved - but apparently hasn't, and I<br>
> >>> think it is fundamentally a broken design without it - so I'd really<br>
> >>> like to see it re-visited.<br>
> >>><br>
> >>> The problem can be described by the following lemma (if you take 'lemma'<br>
> >>> to mean 'a sentence I came up with just now' :)):<br>
> >>><br>
> >>> """<br>
> >>> Due to the way scheduling works in Nova (roughly: pick a host based on<br>
> >>> stale(ish) data, rely on claims to trigger a re-schedule), _same exact_<br>
> >>> information that scheduling service used when making a placement<br>
> >>> decision, needs to be available to the compute service when testing the<br>
> >>> placement.<br>
> >>> “""<br>
> >><br>
> >> Correct<br>
> >><br>
> >>> This is not the case right now, and the ERT does not propose any way to<br>
> >>> solve it - (see how I hacked around needing to be able to get<br>
> >>> extra_specs when making claims in [3], without hammering the DB). The<br>
> >>> result will be that any resource that we add and needs user supplied<br>
> >>> info for scheduling an instance against it, will need a buggy<br>
> >>> re-implementation of gathering all the bits from the request that<br>
> >>> scheduler sees, to be able to work properly.<br>
> >><br>
> >> Agreed, ERT does not attempt to solve this problem of ensuring RT has an<br>
> >> identical set of information for testing claims.  I don’t think it was<br>
> >> intended to.<br>
> >><br>
> >> ERT does solve the issue of bloat in the RT with adding<br>
> >> just-one-more-thing to test usage-wise.  It gives a nice hook for inserting<br>
> >> your claim logic for your specific use case.<br>
> ><br>
> ><br>
> > I think Nikola and I agreed on the fact that ERT is not responsible for this<br>
> > design. That said I can talk on behalf of Nikola...<br>
> ><br>
> ><br>
> ><br>
> >>> This is obviously a bigger concern when we want to allow users to pass<br>
> >>> data (through image or flavor) that can affect scheduling, but still a<br>
> >>> huge concern IMHO.<br>
> >><br>
> >> I think passing additional data through to compute just wasn’t a problem<br>
> >> that ERT aimed to solve.  (Paul Murray?)  That being said, coordinating the<br>
> >> passing of any extra data required to test a claim that is *not* sourced<br>
> >> from the host itself would be a very nice addition.  You are working around<br>
> >> it with some caching in your flavor db lookup use case, although one could<br>
> >> of course cook up a cleaner patch to pass such data through on the “build<br>
> >> this” request to the compute.<br>
> ><br>
> ><br>
> > Indeed, and that's why I think the problem can be resolved thanks to 2<br>
> > different things :<br>
> > 1. Filters need to look at what ERT is giving them, that's what<br>
> > isolate-scheduler-db is trying to do (see my patches [2.3 and 2.4] on the<br>
> > previous emails<br>
> > 2. Some extra user request needs to be checked in the test() method of ERT<br>
> > plugins (where claims are done), so I provided a WIP patch for discussing it<br>
> > : <a href="https://review.openstack.org/#/c/113936/">https://review.openstack.org/#/c/113936/</a><br>
> ><br>
> ><br>
> ><br>
> >>> As I see that there are already BPs proposing to use this IMHO broken<br>
> >>> ERT ([4] for example), which will surely add to the proliferation of<br>
> >>> code that hacks around these design shortcomings in what is already a<br>
> >>> messy, but also crucial (for perf as well as features) bit of Nova code.<br>
> >>><br>
> >>> I propose to revert [2] ASAP since it is still fresh, and see how we can<br>
> >>> come up with a cleaner design.<br>
> >>><br>
> >> I think the ERT is forward-progress here, but am willing to review<br>
> >> patches/specs on improvements/replacements.<br>
> ><br>
> ><br>
> > Sure, your comments are welcome on <a href="https://review.openstack.org/#/c/113373/">https://review.openstack.org/#/c/113373/</a><br>
> > You can find an example where TypeAffinity filter is modified to look at<br>
> > HostState and where ERT is being used for updating HostState and for<br>
> > claiming resource.<br>
> ><br>
> ><br>
> ><br>
> >><br>
> >>> Would like to hear opinions on this, before I propose the patch tho!<br>
> >>><br>
> >>> Thanks all,<br>
> >>><br>
> >>> Nikola<br>
> >>><br>
> >>> [1]<br>
> >>> <a href="https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement">https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement</a><br>
> >>> [2] <a href="https://review.openstack.org/#/c/109643/">https://review.openstack.org/#/c/109643/</a><br>
> >>> [3] <a href="https://review.openstack.org/#/c/111782/">https://review.openstack.org/#/c/111782/</a><br>
> >>> [4] <a href="https://review.openstack.org/#/c/89893">https://review.openstack.org/#/c/89893</a><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>
> >><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>
> ><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>
><br>
><br>
><br>
> --<br>
> Rackspace Australia<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>