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 the
proper 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
