Train Series Release Notes

2.0.0

Prelude

The 2.0.0 release of placement is the first release where placement is available solely from its own project and must be installed separately from nova. If the extracted placement is not already in use, prior to upgrading to Train, the Stein version of placement must be installed. See Upgrading from Nova to Placement for details.

2.0.0 adds a suite of features which, combined, enable targeting candidate providers that have complex trees modeling NUMA layouts, multiple devices, and networks where affinity between and grouping among the members of the tree are required. These features will help to enable NFV and other high performance workloads in the cloud.

Also added is support for forbidden aggregates which allows groups of resource providers to only be used for specific purposes, such as reserving a group of compute nodes for licensed workloads.

Extensive benchmarking and profiling have led to massive performance enhancements, especially in environments with large numbers of resource providers and high concurrency.

New Features

  • In microversion 1.34 the body of the response to a GET /allocation_candidates request has been extended to include a mappings field with each allocation request. The value is a dictionary associating request group suffixes with the uuids of those resource providers that satisfy the identified request group. For convenience, this mapping can be included in the request payload for POST /allocations, PUT /allocations/{consumer_uuid}, and POST /reshaper, but it will be ignored.

  • From microversion 1.36, a new same_subtree queryparam on GET /allocation_candidates is supported. It accepts a comma-separated list of request group suffix strings ($S). Each must exactly match a suffix on a granular group somewhere else in the request. Importantly, the identified request groups need not have a resources$S. If this is provided, at least one of the resource providers satisfying a specified request group must be an ancestor of the rest. The same_subtree query parameter can be repeated and each repeated group is treated independently.

  • Microversion 1.35 adds support for the root_required query parameter to the GET /allocation_candidates API. It accepts a comma-delimited list of trait names, each optionally prefixed with ! to indicate a forbidden trait, in the same format as the required query parameter. This restricts allocation requests in the response to only those whose (non-sharing) tree’s root resource provider satisfies the specified trait requirements.

  • In microversion 1.33, the syntax for granular groupings of resource, required/forbidden trait, and aggregate association requests introduced in 1.25 has been extended to allow, in addition to numbers, strings from 1 to 64 characters in length consisting of a-z, A-Z, 0-9, _, and -. This is done to allow naming conventions (e.g., resources_COMPUTE and resources_NETWORK) to emerge in situations where multiple services are collaborating to make requests.

  • Add support for forbidden aggregates in member_of queryparam in GET /resource_providers and GET /allocation_candidates. Forbidden aggregates are prefixed with a ! from microversion 1.32.

    This negative expression can also be used in multiple member_of parameters:

    ?member_of=in:<agg1>,<agg2>&member_of=<agg3>&member_of=!<agg4>

    would translate logically to

    “Candidate resource providers must be at least one of agg1 or agg2, definitely in agg3 and definitely not in agg4.”

    We do NOT support ! within the in: list:

    ?member_of=in:<agg1>,<agg2>,!<agg3>

    but we support !in: prefix:

    ?member_of=!in:<agg1>,<agg2>,<agg3>

    which is equivalent to:

    ?member_of=!<agg1>&member_of=!<agg2>&member_of=!<agg3>

    where returned resource providers must not be in agg1, agg2, or agg3.

    Specifying forbidden aggregates in granular requests, member_of<N> is also supported from the same microversion, 1.32.

Upgrade Notes

  • The Missing Root Provider IDs upgrade check in the placement-status upgrade check command will now produce a failure if it detects any resource_providers records with a null root_provider_id value. Run the placement-manage db online_data_migrations command to heal these types of records.

Deprecation Notes

  • The [placement]/policy_file configuration option is deprecated and its usage is being replaced with the more standard [oslo_policy]/policy_file option. If you do not override policy with custom rules you will have nothing to do. If you do override the placement default policy then you will need to update your configuration to use the [oslo_policy]/policy_file option. By default, the [oslo_policy]/policy_file option will be used if the file it points at exists.

Bug Fixes

  • By fixing bug story/2005842 the OSProfiler support works again in the placement WSGI.

  • Limiting nested resource providers with the limit=N query parameter when calling GET /allocation_candidates could result in incomplete provider summaries. This is now fixed so that all resource providers that are in the same trees as any provider mentioned in the limited allocation requests are shown in the provider summaries collection. For more information see story/2005859.