Hi, more resource providers and placement information for your reading pleasure. Things continue to move along, with plenty of stuff to review and a new bug that someone could work on.
# What Matters Most The main priority remains the same: Getting the scheduler using a filtered list of resource providers. That work is in progress near here: https://review.openstack.org/#/c/392569/ # Stuff that's Different Now Discussion about the upgrade process from newton (where placement is optional) to ocata (where we _really_ want it to be required) has led the placement client in the resource tracker (and eventually the scheduler) to change from trying the placement API and not retrying on failure to retrying with a log warning: https://review.openstack.org/#/c/418590/ The aggregates api will now return the uuid of an aggreate in the JSON representation. # Stuff Needing a Plan # can_host, aggregates in filtering See: http://lists.openstack.org/pipermail/openstack-dev/2017-January/109971.html in which I go an at some length on this topic in response to last week's update, but no one has yet confirmed or denied the concerns. # Pending Planned Work ## Dev Documentation Work has started on documentation for developers of the placement API. It is under review starting at https://review.openstack.org/#/c/411946/ ## Handling Aggregates in Placement Server and Clients Resource tracker handling of aggregates is the last big piece for aggregate handling: https://review.openstack.org/#/c/407309/ The server side change has merged, after some stumbling over theproper handling of mircoversions: there was a non-microversioned code on master that enabled the `member_of` feature to exist, but
not actually work. The link to the archive above is about the when of arggegate handling for the scheduler. ## Resource Tracker Cleanup and Use of Resource Classes For Ironic The cleanup to the resource tracker so that it can be more effective and efficient and work correctly with Ironic continues in the custom-resource-classes topic: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/custom-resource-classes # Stuff Happening Outside of Nova * Neutron IPV4 Inventory https://review.openstack.org/#/c/358658/ * Continued puppet/tripleo work with placement https://review.openstack.org/#/c/406309/ # Bugs, Pick up Work, and Miscellaneous * Allocation bad input handling and dead code fixing https://review.openstack.org/#/c/419137/ This has turned out to be a goldmine for finding bugs. In addition to fixing how allocations are created and removing dead code, it also exposed that resource provider objects were not having their generation being updated in the right places at the right times and a bug in gabbi related to exposing failures in fixtures. * Update the generic resource pools spec to reflect reality https://review.openstack.org/#/c/407562/ * [WIP] Placement api: Add json_error_formatter to defaults https://review.openstack.org/#/c/395194/ This is an effort to avoid boilerplate, but no good solution has been determined yet. Reviewers can help us figure a good way to handle things. * Demo inventory update script: https://review.openstack.org/#/c/382613/ This one might be considered a WIP because how it chooses to do things (rather simply and dumbly) may not be in line with expecations. * CORS support in placement API: https://review.openstack.org/#/c/392891/ * Better debug logging on inventory update failures https://review.openstack.org/#/c/414230/ The request-id wasn't being recorded, which makes it difficult to associate client side logs with server side logs. * Capacity exceeded logging is in the wrong place https://review.openstack.org/#/c/410128/ * Python3 fixes that include changes in placement https://review.openstack.org/#/c/419476/ JSON bodies need to be bytes in python3. The code was written assuming webob would take care of this but it doesn't. The plan is for code like this to merge, and then a follow up to back it out in favor of an `EncodeUTF8` middleware, removing the need for boilerplate on all handlers. * Backports to Newton https://review.openstack.org/#/q/owner:mriedem%2540us.ibm.com+status:open+branch:stable/newton MattR has a passel of backports to newton, several of which are placement but fixes. * NEW BUG: DiscoveryFailure when trying to get resource providers https://bugs.launchpad.net/nova/+bug/1656075 This is a newly discovered bug of yet another exception raised by keystoneauth1 that is not being handled. # Post Ocata ## Resource Provider Traits Proof of concept work on resource provider traits is seeing plenty of activity lately. This is the functionality that will allow people to express requirements and preferences about qualitative aspects of resources. https://review.openstack.org/#/q/status:open+branch:master+topic:bp/resource-provider-tags Spec: https://review.openstack.org/#/c/345138/ ## Nested Resource Providers This is moving along at: https://review.openstack.org/#/c/377138/ ## Delete all Inventory Working with the placement API from the resource tracker identified an inefficient with the API: it's hard to delete all of one resource provider's inventory in one request if it has more than one class of resource. Work is planned to fix it: spec: https://review.openstack.org/#/c/415885/ imp: https://review.openstack.org/416669 ## Detailed error information for placement API 4xx responses from the Placement API can sometimes mean different things for the same response code, especially with 409 responses. A spec has been started to more fully implement the errors guideline from the API-WG so that a unique code is associated with particular error situations: spec: https://review.openstack.org/#/c/418393/ # End Despite efforts to avoid it I seem to be getting ill, so if this is missing something I blame that (and society, man) and I hope anyone who notices will followup with a correction. Thanks. -- 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