Open Stack

On 4/7/2017 8:35 AM, Chris Dent wrote:
>
> There was a nova-specs sprint this week, so a lot of eyes were on
> specs but there continues to be regular progress on resource
> providers, the placement API and related work in the scheduler and
> resource tracker. If you're doing work that I haven't noticed and
> reported in here that you think should be, please follow up with
> some links.
>
> # What Matters Most
>
> The addition of traits to the placement API is very close, one patch
> remains. Linked below. That means that the top of the priority stack
> is the spec for claims via the scheduler. Also linked below.
>
> # What's Changed
>
> There's a new spec for including user and project information in
> allocations. This is a start towards allowing placement info to be
> used for the counting required for quotas. There's a spec and a
> followup review to fix some issues with it:
>
>
> http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-project-user.html
>
>     https://review.openstack.org/#/c/454352/
>
> # Help Wanted
>
> Areas where volunteers are needed.
>
> * General attention to bugs tagged placement:
>     https://bugs.launchpad.net/nova/+bugs?field.tag=placement
>
> * Helping to create api documentation for placement (see the Docs
>     section below).
>
> * Helping to create and evaluate functional tests of the resource
>     tracker and the ways in which it and nova-scheduler use the
>     reporting client. For some info see
>     https://etherpad.openstack.org/p/nova-placement-functional
>     and talk to edleafe.
>
> * Performance testing. If you have access to some nodes, some basic
>    benchmarking and profiling would be very useful. See the
>    performance section below. Is there room on OSIC for this kind of
>    thing?
>
> # Main Themes
>
> ## Traits
>
> The work to implement the traits API in placement is happening at
>
>
> https://review.openstack.org/#/q/status:open+topic:bp/resource-provider-traits
>
>
> There's one patch left to get the API in place and a patch for a new
> command to sync the os-traits library into the database:
>
>     https://review.openstack.org/#/c/450125/
>
> There is a stack of changes to the os-traits library to add more traits
> and also automate creating symbols associated with the trait
> strings:
>
>     https://review.openstack.org/#/c/448282/4
>
> ## Ironic/Custom Resource Classes
>
> There's a blueprint for "custom resource classes in flavors" that
> describes the stuff that will actually make use of custom resource
> classes:
>
>
> https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-in-flavors
>
>
> The spec has merged, but the implementation has not yet started.
>
> Over in Ironic some functional and integration tests have started:
>
>     https://review.openstack.org/#/c/443628/
>
> ## Claims in the Scheduler
>
> Progress has been made on the spec for claims in the scheduler:
>
>     https://review.openstack.org/#/c/437424/
>
> Some differences of opinion on what's possible now and what the API
> should expose have been resolved, but now we need to resolve some
> questions on how (or even if) to most effectively deal with
> reconciling allocations that used to happen in the resource tracker
> and will now happen in the scheduler.
>
> Eyes and brains required.
>
> Thinking about this stuff has also revealed some places where it's
> possible for allocations to become wrong or orphaned:
>
>     https://bugs.launchpad.net/nova/+bug/1679750
>     https://bugs.launchpad.net/nova/+bug/1661312
>
> ## Shared Resource Providers
>
> https://blueprints.launchpad.net/nova/+spec/shared-resources-pike
>
> Progress on this will continue once traits and claims have moved forward.
>
> ## Nested Resource Providers
>
> The spec for this has been updated with what was learned at the PTG
> and moved to pike and merged:
>
>
> http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/nested-resource-providers.html
>
>
> ## Docs
>
> https://review.openstack.org/#/q/topic:cd/placement-api-ref
>
> Several reviews are in progress for documenting the placement API.
> This is likely going to take quite a few iterations as we work out
> the patterns and tooling. But it's great to see the progress and
> when looking at the draft rendered docs it makes placement feel like
> a real thing™.
>
> Find me (cdent) or Andrey (avolkov) if you want to help out or have
> other questions.
>
> ## Performance
>
> We're aware that there are some redundancies in the resource tracker
> that we'd like to clean up
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html
>
> but it's also the case that we've done no performance testing on the
> placement service itself.
>
> We ought to do some testing to make sure there aren't unexpected
> performance drains. Is this something where we could get time on the
> OSIC hardware?
>
> # Other Code/Specs
>
> * https://review.openstack.org/#/c/418393/
>      A spec for improving the level of detail and structure in placement
>      error responses so that it is easier to distinguish between
>      different types of, for example, 409 responses.
>
>      This hasn't seen any attention since March 17, and as a result
>      didn't get any attention during the spec sprint, so it might
>      not make the freeze.
>
> * https://review.openstack.org/#/c/448791/
>     Idempotent PUT for resource classes. This is something that was
>     discovered while evaluating some resource tracker code. Has a
>     spec too:
>     https://review.openstack.org/#/c/453732/
>
> * https://bugs.launchpad.net/nova/+bug/1632852
>       Cache headers not produced by placement API. This was assigned to
>       several different people over time, but I'm not sure if there is
>       any active code.
>
> * https://etherpad.openstack.org/p/placement-newton-leftovers
>        There's still some lingering stuff on here, some of which is
>        mentioned elsewhere in this message, but not all.
>
> # End
>
> One of the best things about writing these things each week is I get
> to see very clearly just how productive we're being in the realm of
> placement. Thanks to everyone who is helping to make that possible.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Speaking of performance, this came to me today when reviewing a change 
to add a uuid column to the services table:

https://review.openstack.org/#/c/454887/

If the filter scheduler is pulling compute nodes from the database with 
a list of uuids, we should have those uuids indexed.

-- 

Thanks,

Matt