> -----Original Message----- > From: Nikola Đipanov [mailto:ndipa...@redhat.com] > Sent: Tuesday, August 12, 2014 3:22 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [Nova] Concerns around the Extensible Resource > Tracker design - revert maybe? > > Hey Nova-istas, > > While I was hacking on [1] I was considering how to approach the fact > that we now need to track one more thing (NUMA node utilization) in our > resources. I went with - "I'll add it to compute nodes table" thinking > it's a fundamental enough property of a compute host that it deserves to > be there, although I was considering Extensible Resource Tracker at one > point (ERT from now on - see [2]) but looking at the code - it did not > seem to provide anything I desperately needed, so I went with keeping it > simple. > > So fast-forward a few days, and I caught myself solving a problem that I > kept thinking ERT should have solved - but apparently hasn't, and I > think it is fundamentally a broken design without it - so I'd really > like to see it re-visited. > > The problem can be described by the following lemma (if you take 'lemma' > to mean 'a sentence I came up with just now' :)): > > """ > Due to the way scheduling works in Nova (roughly: pick a host based on > stale(ish) data, rely on claims to trigger a re-schedule), _same exact_ > information that scheduling service used when making a placement > decision, needs to be available to the compute service when testing the > placement. > """ > > This is not the case right now, and the ERT does not propose any way to > solve it - (see how I hacked around needing to be able to get > extra_specs when making claims in [3], without hammering the DB). The > result will be that any resource that we add and needs user supplied > info for scheduling an instance against it, will need a buggy > re-implementation of gathering all the bits from the request that > scheduler sees, to be able to work properly. > > This is obviously a bigger concern when we want to allow users to pass > data (through image or flavor) that can affect scheduling, but still a > huge concern IMHO.
I'd think this is not ERT itself, but more a RT issue. And the issue happens to PCI also, which has to save the PCI request in the system metadata (No ERT at that time). It will be great to have a more generic solution. Thanks -jyh _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev