<div dir="ltr">Hi Nikola,<div><br></div><div>Firstly, thanks for waiting for me to respond and sorry I was absent for the last couple of weeks.</div><div><br></div><div>The extensible resource tracker bp deals with two distinct information flows:</div>
<div><br></div><div>1. information about resources that is passed from the compute node to the scheduler,</div><div>2. information about resource requirements passed to the scheduler and the compute node.</div><div><br></div>
<div>If I understand your email below correctly, you are saying that information such as extra_specs, is not made available to the compute node or the resource plugins. This is specifically about the second item (2.) above.</div>
<div><br></div><div>The patch that you propose to revert addresses the first item (1.), i.e. it provides a means to select which resources are tracked and to pass that information to the scheduler. It gives us two things: we can add resource plugins and pass information to the scheduler without having to change the resource tracker or scheduler. We can also pick and chose which resource plugins to use, and so what information we want to write to the database and pass to the scheduler.</div>
<div><br></div><div>The ability to omit resource information is as useful as the ability to add it. So if new a resource plugin is added, operators that do not use that information do not need to configure it. As an operator myself, I would be happy to omit the proliferation of compute node details that are coming, while benefiting from those that are of use to me.</div>
<div><br></div><div>The interface for the plugins does not need to be considered a fixed external interface, it is not. It is ok to add necessary parameters if there is no other sensible way to pass information you need.</div>
<div><br></div><div>So in short, the ability to add resource information without impacting everybody is the value that the patch you want to revert brings. If in the future another design is settled on for resource tracking and scheduling it will still have to face the same requirement. The compute node will have a set of resource information that could be tracked and used, but not everyone will want the overhead of discovering and reporting all of it, so they should not need to have all of it.</div>
<div><br></div><div>Paul</div><div><br></div><div><br></div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 August 2014 10:11, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since after a week of discussing it I see no compelling argument against<br>
reverting it - here's the proposal:<br>
<br>
   <a href="https://review.openstack.org/115218" target="_blank">https://review.openstack.org/115218</a><br>
<br>
Thanks,<br>
N.<br>
<div class="HOEnZb"><div class="h5"><br>
On 08/12/2014 12:21 PM, Nikola Đipanov wrote:<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>
> 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>
> 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>
> 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>
> Would like to hear opinions on this, before I propose the patch tho!<br>
><br>
> Thanks all,<br>
><br>
> Nikola<br>
><br>
> [1] <a href="https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement" target="_blank">https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement</a><br>
> [2] <a href="https://review.openstack.org/#/c/109643/" target="_blank">https://review.openstack.org/#/c/109643/</a><br>
> [3] <a href="https://review.openstack.org/#/c/111782/" target="_blank">https://review.openstack.org/#/c/111782/</a><br>
> [4] <a href="https://review.openstack.org/#/c/89893" target="_blank">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" target="_blank">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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>