Re: [openstack-dev] [nova] [placement] resource providers update 44
On 12/8/2017 7:57 AM, Chris Dent wrote: I'm feeling pressure from the (excellent and welcomed) Weekly Owl http://lists.openstack.org/pipermail/openstack-dev/2017-December/125214.html and Keystone update: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125112.html to enhance the rp and placement update brand, to maximize market penetration, global influence, and reader participation, but instead I'll stick to habit. # Most Important The three main themes (nested providers, alternate hosts, migration) continue to be the main priorities. A thing to be aware of, now that some of nested has merged on the placement side, is that the nova side is underway and the work surrounding the ProviderTree concept is fairly penetrating. It will supersede the "get_inventory" method in the virt drivers, and thus far not all the virt drivers have get_inventory methods. See https://review.openstack.org/#/c/521187/ way down inside the nested-resource-providers topic for a bit of context. # What's Changed Microversion 1.14 has merged (causing a might microversion conflict pileup behind it) meaning that some aspects of nested providers are in the placement API. Hierarchies of providers can be created, and trees of results can be returned: https://developer.openstack.org/api-ref/placement/#create-resource-provider https://developer.openstack.org/api-ref/placement/#list-resource-providers I didn't help with the reviews when this merged, but did ask some questions about the "in_tree" filter functionality added in a review today: https://review.openstack.org/#/c/520663/9/nova/tests/unit/scheduler/client/test_report.py@1400 It would be helpful for me, and I'll assume others, if we had something more in the API reference docs with example provider trees and what the results would be when listing providers with specific nodes in that tree, i.e. define what a "provider tree" is - where does it stop? I don't know if that's good to bake into the API reference parameter description itself or create it's own doc page to link to for an explanation and example usage. A fix was merged that defaults the accept header, if not set, to application/json. This means that whereas in the past an error response could inadvertently be HTML, it will now be JSON, structured (partially, critically the 'code' field is not there as we've stumbled trying to create standards) according to the errors guideline: https://review.openstack.org/#/c/518223/ http://specs.openstack.org/openstack/api-wg/guidelines/errors.html Eric made the compute node be more alert when it encounters an error condition when getting or creating resource providers: https://review.openstack.org/#/c/524263/ This led to the discovery that in grenade placement was not being properly stopped and restarted over the upgrade transition: https://review.openstack.org/#/c/525605/ I mention all this because it's quite likely that latent bugs with talking to placement (from nova) in grenade will be exposed. Be on the lookout. If you find something weird, report a bug, and if possible, fix it. # Help Wanted (unchanged from last week, no new data, yet) A takeaway from summit is that we need, where possible, benchmarking info from people who are making the transition from old methods of scheduling to the newer allocation_candidate driven modes. While detailed numbers will be most useful, even anecdotal summaries of "woot it's way better" or "hmmm, no it seems worse" are useful. # Docs Quite a few docs improvements have merged. Others need more review: * https://review.openstack.org/#/c/512215/ Add create inventories doc for placement * https://review.openstack.org/#/c/523007/ Add x-openstack-request-id in API ref * https://review.openstack.org/#/c/521541/ Add 'Location' parameters in API ref * https://review.openstack.org/#/c/511342/ add API reference for create inventory # Nested Providers The nested-resource-providers stack has grown a long tail of changes for managing nested providers rooted on a compute node: https://review.openstack.org/#/q/topic:bp/nested-resource-providers As mentioned above this has impact for virt drivers. The current spec for nested providers http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html doesn't really cover the ProviderTree and inventory management plans that are currently being implemented in that long tail. That makes it a bit harder to review than it might otherwise. We may not need a spec but a sort of explanatory overview may help provide some context on what needs to happen. A lot of the work that is in progress feels like it is working to a design where the use cases are not entirely obvious. There's a danger this can lead to an implementation that is somewhat divorced for reality. There's no evidence as yet that this is happening, but there's also none that
[openstack-dev] [nova] [placement] resource providers update 44
I'm feeling pressure from the (excellent and welcomed) Weekly Owl http://lists.openstack.org/pipermail/openstack-dev/2017-December/125214.html and Keystone update: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125112.html to enhance the rp and placement update brand, to maximize market penetration, global influence, and reader participation, but instead I'll stick to habit. # Most Important The three main themes (nested providers, alternate hosts, migration) continue to be the main priorities. A thing to be aware of, now that some of nested has merged on the placement side, is that the nova side is underway and the work surrounding the ProviderTree concept is fairly penetrating. It will supersede the "get_inventory" method in the virt drivers, and thus far not all the virt drivers have get_inventory methods. See https://review.openstack.org/#/c/521187/ way down inside the nested-resource-providers topic for a bit of context. # What's Changed Microversion 1.14 has merged (causing a might microversion conflict pileup behind it) meaning that some aspects of nested providers are in the placement API. Hierarchies of providers can be created, and trees of results can be returned: https://developer.openstack.org/api-ref/placement/#create-resource-provider https://developer.openstack.org/api-ref/placement/#list-resource-providers A fix was merged that defaults the accept header, if not set, to application/json. This means that whereas in the past an error response could inadvertently be HTML, it will now be JSON, structured (partially, critically the 'code' field is not there as we've stumbled trying to create standards) according to the errors guideline: https://review.openstack.org/#/c/518223/ http://specs.openstack.org/openstack/api-wg/guidelines/errors.html Eric made the compute node be more alert when it encounters an error condition when getting or creating resource providers: https://review.openstack.org/#/c/524263/ This led to the discovery that in grenade placement was not being properly stopped and restarted over the upgrade transition: https://review.openstack.org/#/c/525605/ I mention all this because it's quite likely that latent bugs with talking to placement (from nova) in grenade will be exposed. Be on the lookout. If you find something weird, report a bug, and if possible, fix it. # Help Wanted (unchanged from last week, no new data, yet) A takeaway from summit is that we need, where possible, benchmarking info from people who are making the transition from old methods of scheduling to the newer allocation_candidate driven modes. While detailed numbers will be most useful, even anecdotal summaries of "woot it's way better" or "hmmm, no it seems worse" are useful. # Docs Quite a few docs improvements have merged. Others need more review: * https://review.openstack.org/#/c/512215/ Add create inventories doc for placement * https://review.openstack.org/#/c/523007/ Add x-openstack-request-id in API ref * https://review.openstack.org/#/c/521541/ Add 'Location' parameters in API ref * https://review.openstack.org/#/c/511342/ add API reference for create inventory # Nested Providers The nested-resource-providers stack has grown a long tail of changes for managing nested providers rooted on a compute node: https://review.openstack.org/#/q/topic:bp/nested-resource-providers As mentioned above this has impact for virt drivers. The current spec for nested providers http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html doesn't really cover the ProviderTree and inventory management plans that are currently being implemented in that long tail. That makes it a bit harder to review than it might otherwise. We may not need a spec but a sort of explanatory overview may help provide some context on what needs to happen. A lot of the work that is in progress feels like it is working to a design where the use cases are not entirely obvious. There's a danger this can lead to an implementation that is somewhat divorced for reality. There's no evidence as yet that this is happening, but there's also none that it's not. ## Alternate Hosts Having the scheduler request and use alternate hosts: https://review.openstack.org/#/q/topic:bp/return-alternate-hosts This has come unstuck and is moving along, but needs continued eyes. ## Migration allocations Do allocation "doubling" using the migration uuid for the consumer for one half. This is also very close: https://review.openstack.org/#/c/507638/ The concept of migration allocations is what drove the work to enable the POST /allocations handling now at microversion 1.13, so we have the option to start using that power. Dan helpfully left comments in the code to indicate where it could be done. Do we want to consider getting that in before the end of queens, to avoid some racing? ## Misc Traits,
