On Fri, Apr 6, 2018 at 2:54 PM, Chris Dent <cdent...@anticdent.org> wrote:
> > This is "contract" style update. New stuff will not be added to the > lists. > > # Most Important > > There doesn't appear to be anything new with regard to most > important. That which was important remains important. At the > scheduler team meeting at the start of the week there was talk of > working out ways to trim the amount of work in progress by using the > nova priorities tracking etherpad to help sort things out: > > https://etherpad.openstack.org/p/rocky-nova-priorities-tracking > > Update provider tree and nested allocation candidates remain > critical basic functionality on which much else is based. With most > of provider tree done, it's really on nested allocation candidates. > > # What's Changed > > Quite a bit of provider tree related code has merged. > > Some negotiation happened with regard to when/if the fixes for > shared providers is going to happen. I'm not sure how that resolved, > if someone can follow up with that, that would be most excellent. > > Most of the placement-req-filter series merged. > > The spec for error codes in the placement API merged (code is in > progress and ready for review, see below). > > # Questions > > * Eric and I discussed earlier in the week that it might be a good > time to start an #openstack-placement IRC channel, for two main > reasons: break things up so as to limit the crosstalk in the often > very busy #openstack-nova channel and to lend a bit of momentum > for going in that direction. Is this okay with everyone? If not, > please say so, otherwise I'll make it happen soon. > > Fine by me. It's sometimes difficult to follow all the conversations so having a separate channel looks good to me, at least for discussing only about specific Placement questions. For Nova related points (like how to use nested RPs for example with NUMA), maybe #openstack-nova is still the main IRC channel for that. * Shared providers status? > (I really think we need to make this go. It was one of the > original value propositions of placement: being able to accurate > manage shared disk.) > > # Bugs > > * Placement related bugs not yet in progress: https://goo.gl/TgiPXb > 15, -1 on last week > * In progress placement bugs: https://goo.gl/vzGGDQ > 13, +1 on last week > > # Specs > > These seem to be divided into three classes: > > * Normal stuff > * Old stuff not getting attention or newer stuff that ought to be > abandoned because of lack of support > * Anything related to the client side of using nested providers > effectively. This apparently needs a lot of thinking. If there are > some general sticking points we can extract and resolve, that > might help move the whole thing forward? > > * https://review.openstack.org/#/c/549067/ > VMware: place instances on resource pool > (using update_provider_tree) > > * https://review.openstack.org/#/c/545057/ > mirror nova host aggregates to placement API > > * https://review.openstack.org/#/c/552924/ > Proposes NUMA topology with RPs > > * https://review.openstack.org/#/c/544683/ > Account for host agg allocation ratio in placement > > * https://review.openstack.org/#/c/552927/ > Spec for isolating configuration of placement database > (This has a strong +2 on it but needs one more.) > > * https://review.openstack.org/#/c/552105/ > Support default allocation ratios > > * https://review.openstack.org/#/c/438640/ > Spec on preemptible servers > > * https://review.openstack.org/#/c/556873/ > Handle nested providers for allocation candidates > > * https://review.openstack.org/#/c/556971/ > Add Generation to Consumers > > * https://review.openstack.org/#/c/557065/ > Proposes Multiple GPU types > > * https://review.openstack.org/#/c/555081/ > Standardize CPU resource tracking > > * https://review.openstack.org/#/c/502306/ > Network bandwidth resource provider > > * https://review.openstack.org/#/c/509042/ > Propose counting quota usage from placement > > # Main Themes > > ## Update Provider Tree > > Most of the main guts of this have merged (huzzah!). What's left are > some loose end details, and clean handling of aggregates: > > https://review.openstack.org/#/q/topic:bp/update-provider-tree > > ## Nested providers in allocation candidates > > Representing nested provides in the response to GET > /allocation_candidates is required to actually make use of all the > topology that update provider tree will report. That work is in > progress at: > > https://review.openstack.org/#/q/topic:bp/nested-resource-providers > https://review.openstack.org/#/q/topic:bp/nested-resource-pr > oviders-allocation-candidates > > Note that some of this includes the up-for-debate shared handling. > > ## Request Filters > > As far as I can tell this is mostly done (yay!) but there is a loose > end: We merged an updated spec to support multiple member_of > parameters, but it's not clear anybody is currently owning that: > > https://review.openstack.org/#/c/555413/ > > ## Mirror nova host aggregates to placement > > This makes it so some kinds of aggregate filtering can be done > "placement side" by mirroring nova host aggregates into placement > aggregates. > > https://review.openstack.org/#/q/topic:bp/placement-mirror-h > ost-aggregates > > It's part of what will make the req filters above useful. > > ## Forbidden Traits > > A way of expressing "I'd like resources that do _not_ have trait X". > This is ready for review: > > https://review.openstack.org/#/q/topic:bp/placement-forbidden-traits > > ## Consumer Generations > > This allows multiple agents to "safely" update allocations for a > single consumer. There is both a spec and code in progress for this: > > https://review.openstack.org/#/q/topic:bp/add-consumer-generation > > # Extraction > > Small bits of work on extraction continue on the > bp/placement-extract topic: > > https://review.openstack.org/#/q/topic:bp/placement-extract > > The spec for optional database handling got some nice support > but needs more attention: > > https://review.openstack.org/#/c/552927/ > > Jay has declared that he's going to start work on the > os-resources-classes library. > > I've posted a 6th in my placement container playground series: > > https://anticdent.org/placement-container-playground-6.html > > Though not directly related to extraction, that experimentation has > exposed a lot of the areas where work remains to be done to make > placement independent of nova. > > A recent experiment with shrinking the repo to just the placement > dir reinforced a few things we already know: > > * The placement tests need their own base test to avoid 'from nova > import test' > * That will need to provide database and other fixtures (such a > config and the self.flags feature). > * And, of course, eventually, config handling. The container > experiments above demonstrate just how little config placement > actually needs (by design, let's keep it that way). > > # Other > > This is a contract week, so nothing new has been added here, despite > there being new work. Part of the intent here it make sure we are > queue-like where we can be. This list maintains its ordering from > week to week: newly discovered things are added to the end. > > There are 14 entries here, -7 on last week. > > That's good. However some of the removals are the result of some > code changing topic (and having been listed here by topic). Some of > the oldest stuff at the top of the list has not moved. > > * https://review.openstack.org/#/c/546660/ > Purge comp_node and res_prvdr records during deletion of > cells/hosts > > * https://review.openstack.org/#/q/topic:bp/placement-osc-plugin-rocky > A huge pile of improvements to osc-placement > > * https://review.openstack.org/#/c/546713/ > Add compute capabilities traits (to os-traits) > > * https://review.openstack.org/#/c/524425/ > General policy sample file for placement > > * https://review.openstack.org/#/c/546177/ > Provide framework for setting placement error codes > > * https://review.openstack.org/#/c/527791/ > Get resource provider by uuid or name (osc-placement) > > * https://review.openstack.org/#/c/477478/ > placement: Make API history doc more consistent > > * https://review.openstack.org/#/c/556669/ > Handle agg generation conflict in report client > > * https://review.openstack.org/#/c/556628/ > Slugification utilities for placement names > > * https://review.openstack.org/#/c/557086/ > Remove usage of [placement]os_region_name > > * https://review.openstack.org/#/c/556633/ > Get rid of 406 paths in report client > > * https://review.openstack.org/#/c/537614/ > Add unit test for non-placement resize > > * https://review.openstack.org/#/c/554357/ > Address issues raised in adding member_of to GET /a-c > > * https://review.openstack.org/#/c/493865/ > cover migration cases with functional tests > > # End > > 2 runway slots open up this coming Wednesday, the 11th. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev