Open Stack

On Fri, Apr 6, 2018 at 2:54 PM, Chris Dent <cdent+os at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180409/167c7c48/attachment.html>