Re: [openstack-dev] [nova] [placement] resource providers update 36
On Oct 6, 2017, at 8:21 AM, Chris Dent wrote: > The extent to which an > allocation request is not always opaque and the need to be explicit > about microversions was clarified, so edleafe is going to make some > adjustments, after first resolving the prerequisite code (alternate > hosts: https://review.openstack.org/#/c/486215/ ). For the record, what was clarified was that the agreement that the allocation_request blob that had been previously agreed to as an opaque blob had been compromised by some last-minute hacks to get migrations working before the Pike deadline. As a result of this change, it was now necessary to add versioning to these allocation_request objects, because now Nova or any other service could be altering them as they saw fit. I still think that this is a terrible design, but I will bow to the pressure to go along with accommodating the change to the previous design. -- Ed Leafe signature.asc Description: Message signed with OpenPGP __ 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-dev] [nova] [placement] resource providers update 36
Update 37 is struggling to contain itself, too much code associated with placement! # Most Important^wRecent Discussion last night uncovered some disagreement and confusion over the content of the Selection object that will be used to send alternate destination hosts when doing builds. The extent to which an allocation request is not always opaque and the need to be explicit about microversions was clarified, so edleafe is going to make some adjustments, after first resolving the prerequisite code (alternate hosts: https://review.openstack.org/#/c/486215/ ). # What's Changed Nested providers spec merged, selection objects spec merged (but see above and below), alternate hosts spec merge, request traits in nova spec merged, minimal cache header spec merged, POST /allocations spec merged. * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/migration-allocations.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/placement-cache-headers.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/post-allocations.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/request-traits-in-nova.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/return-alternate-hosts.html * http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/return-selection-objects.html There are additional specs not yet merged, placement related, some of which the above depend on, that need some attention. * https://review.openstack.org/#/c/502306/ Network bandwidth resource provider * https://review.openstack.org/#/c/507052/ Support traits in the Ironic driver * https://review.openstack.org/#/c/508164/ Add spec for symmetric GET and PUT of allocations (The POST /allocations spec depends on this one) * https://review.openstack.org/#/c/509136/ Fix issues for post-allocations spec * https://review.openstack.org/#/c/504540/ Spec for limiting GET /allocation_candidates * https://review.openstack.org/#/c/497713/ Add trait support in the allocation candidates API # Main Themes ## Nested Resource Providers While working on nested resource providers it became clear there was a lot of mixed up crusted in the resource provider objects, so before the nested work there is now https://review.openstack.org/#/q/status:open+topic:no-orm-resource-providers which is a stack of cleanups to how the SQL is managed in there. When that is done, the conflicts at https://review.openstack.org/#/q/status:open+topic:no-orm-resource-providers will be resolved and nested work will continue. ## Migration allocations The migration allocations work is happening at: https://review.openstack.org/#/q/topic:bp/migration-allocations Management of those allocations currently involves some raciness, birthing the specs (above) to allow POST /allocations, some of the code for that is in progress at https://review.openstack.org/#/q/topic:bp/post-allocations ## Alternate Hosts We want to be able to do retries within cells, so we need some alternate hosts when returning a destination that are structured nicely for RPC: https://review.openstack.org/#/q/topic:bp/return-selection-objects # Other Stuff * https://review.openstack.org/#/c/508149/ A spec in neutron for QoS minimum bandwidth allocation in Placement API There's plenty of other other stuff too, but much of it is covered in the links above to avoid a tyranny of choice, I'll just leave it off for now. There's plenty of existing stuff to think about. # End Your prize this week is vegetable tempura. -- 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-dev] [nova] placement/resource providers update 36
Update 36, accelerating into the cycle, is thinking about specs. # Most Important There are several specs outstanding for the main placement-related work that is prioritized for this cycle. And some of those specs have spin off specs inspired by them. Since a spec sprint is planned for early next week, I'll break with tradition and format things differently this time to put some emphasis on specs to be clear that we need to get those out of the way. The three main priorities are migration uuid for allocations, alternate hosts, and nested providers. ## Nested Resource Proivders The nested resource providers spec is at https://review.openstack.org/#/c/505209/ It was previously accepted, but with all the recent talk about dealing with traits on nested providers there's some discussion happening there. There's a passel of related specs, about implementing traits in various ways: * https://review.openstack.org/#/c/497713/ Add trait support in the allocation candidates API * https://review.openstack.org/#/c/468797/ Request traits in Nova John has started a spec about using traits with Ironic: https://review.openstack.org/#/c/507052/ The NRP implementation is at: https://review.openstack.org/#/q/topic:bp/nested-resource-providers ## Migration allocations The migration allocations spec has already merged https://review.openstack.org/#/c/498510/ and the work for it is ongoing at: https://review.openstack.org/#/q/topic:bp/migration-allocations Management of those allocations currently involves some raciness, plans to address that are captured in: * https://review.openstack.org/#/c/499259/ Add a spec for POST /allocations in placement but that proposes a change in the allocation representation which ought to first be reflected in PUT /allocations/{consumer_uuid}, that's at: * https://review.openstack.org/#/c/508164/ Add spec for symmetric GET and PUT of allocations ## Alternate Hosts We want to be able to do retries within cells, so we need some alternate hosts when returning a destination, the spec for that is: https://review.openstack.org/#/c/504275/k We want that data to be formatted in a way that causes neither fear nor despair, so a spec for "Selection" objects exists: https://review.openstack.org/#/c/498830/ Implementation ongoing at: https://review.openstack.org/#/q/topic:bp/placement-allocation-requests+status:open ## Other Specs * https://review.openstack.org/#/c/496853/ Add a spec for minimal cache headers in placement * https://review.openstack.org/#/c/504540/ Spec for limiting GET /allocation_candidates (This one needs some discussion about what the priorities are, lots of good but different ideas on the spec) * https://review.openstack.org/#/c/502306/ Network bandwitdh resource provider # End Next time we'll go back to the usual format. -- 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