Re: [openstack-dev] [nova] [placement] resource providers update 36

[Ed Leafe]

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

[Chris Dent]

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

[Chris Dent]

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