Project: openstack/api-site  2850130977c6b742bbe921237350ce31aeef596f

Add volume attributes description for Block Storage API

For v1
  #1: Add status attribute for JSON sample
  #2: Fix snapshot_id, source_volid description for response side.
  #3: Add attachments non-null sample

For v2
  Add volume info response attributes

Change-Id: Iebe1eb2f12550d0e66bb594468ce6b28c9d3c756
Closes-Bug: #1331246

Project: openstack/api-site  0c1f7cacd19e1175ea583c54f7a566fa1f3a74bd

Compute v2.1 docs clean up (part 7) (security_group_default_rules)

Add os-security-group-default-rules
  it is based on v2 ext file.
    changes are #1 remove xml file, #2 change /v2 => /v2.1
    JSON samples are not edited/changed.

  Also ordering is alphabetical
    os-security-groups
    os-security-group-default-rules <= added
    os-security-group-rules

Change-Id: I4c06148fe45b32f1aa936bba14d71cd6328fe439
Partial-Bug: #1488144

Project: openstack/api-site  a3df332507cadc3d75f15f43f6de0016424d62ec

Compute v2.1 docs clean up (part 8) (fixed_ips)

Add os-fixed-ips
  it is based on v2 ext file
    Changes are #1 remove link to xml sample file
                #2 change /v2 => /v2.1
    JSON samples are not edited/changed.

Change-Id: I8da2147514bc4940532953951f3310dc6ba0fef7
Partial-Bug: #1488144

Project: openstack/python-neutronclient  7b4ef5d858e4715bb637f66b8d4efbe11de37bab

neutron v2 command module cleanup #1

Purge "body[resource].update({key: value})" pattern
and use "body[key] = value" pattern.
The purged pattern is a bad convention in neutronclient and
I commented not to use it many times but I got tired of it.

Change-Id: I2fe0be30d648f59fa45c5951ccc5060c35527aff

Project: openstack/python-neutronclient  7b4ef5d858e4715bb637f66b8d4efbe11de37bab

neutron v2 command module cleanup #1

Purge "body[resource].update({key: value})" pattern
and use "body[key] = value" pattern.
The purged pattern is a bad convention in neutronclient and
I commented not to use it many times but I got tired of it.

Change-Id: I2fe0be30d648f59fa45c5951ccc5060c35527aff

Project: openstack/swift  c799d4de5296056b06e08d8025488472cfcb7d66

Validate against duplicate device part replica assignment

We should never assign multiple replicas of the same partition to the
same device - our on-disk layout can only support a single replica of a
given part on a single device.  We should not do this, so we validate
against it and raise a loud warning if this terrible state is ever
observed after a rebalance.

Unfortunately currently there's a couple not necessarily uncommon
scenarios which will trigger this observed state today:

 1. If we have less devices than replicas
 2. If a server or zones aggregate device weight make it the most
    appropriate candidate for multiple replicas and you're a bit unlucky

Fixing #1 would be easy, we should just not allow that state anymore.
Really we never did - if you have a 3 replica ring with one device - you
have one replica.  Everything that iter_nodes'd would de-dupe.  We
should just be insisting that you explicitly acknowledge your replica
count with set_replicas.

I have been lost in the abyss for days searching for a general solutions
to #2.  I'm sure it exists, but I will not have wrestled it to
submission by RC1.  In the meantime we can eliminate a great deal of the
luck required simply by refusing to place more than one replica of a
part on a device in assign_parts.

The meat of the change is a small update to the .validate method in
RingBuilder.  It basically unrolls a pre-existing (part, replica) loop
so that all the replicas of the part come out in order so that we can
build up the set of dev_id's for which all the replicas of a given part
are assigned part-by-part.

If we observe any duplicates - we raise a warning.

To clean the cobwebs out of the rest of the corner cases we're going to
delay get_required_overload from kicking in until we achive dispersion,
and a small check was added when selecting a device subtier to validate
if it's already being used - picking any other device in the tier works
out much better.  If no other devices are available in the tier - we
raise a warning.  A more elegant or optimized solution may exist.

Many unittests did not meet the criteria #1, but the fix was straight
forward after being identified by the pigeonhole check.

However, many more tests were affected by #2 - but again the fix came to
be simply adding more devices.  The fantasy that all failure domains
contain at least replica count devices is prevalent in both our ring
placement algorithm and it's tests.  These tests were trying to
demonstrate some complex characteristics of our ring placement algorithm
and I believe we just got a bit too carried away trying to find the
simplest possible example to demonstrate the desirable trait.  I think
a better example looks more like a real ring - with many devices in each
server and many servers in each zone - I think more devices makes the
tests better.  As much as possible I've tried to maintain the original
intent of the tests - when adding devices I've either spread the weight
out amongst them or added proportional weights to the other tiers.

I added an example straw man test to validate that three devices with
different weights in three different zones won't blow up.  Once we can
do that without raising warnings and assigning duplicate device part
replicas - we can add more.  And more importantly change the warnings to
errors - because we would much prefer to not do that #$%^ anymore.

Co-Authored-By: Kota Tsuyuzaki <tsuyuzaki.kota@lab.ntt.co.jp>
Related-Bug: #1452431
Change-Id: I592d5b611188670ae842fe3d030aa3b340ac36f9

Project: openstack/swift  0553d9333ed0045c4d209065b315533a33e5d7d7

Put part-replicas where they go

It's harder than it sounds.  There was really three challenges.

Challenge #1 Initial Assignment
===============================

Before starting to assign parts on this new shiny ring you've
constructed, maybe we'll pause for a moment up front and consider the
lay of the land.  This process is called the replica_plan.

The replica_plan approach is separating part assignment failures into
two modes:

 1) we considered the cluster topology and it's weights and came up with
    the wrong plan

 2) we failed to execute on the plan

I failed at both parts plenty of times before I got it this close.  I'm
sure a counter example still exists, but when we find it the new helper
methods will let us reason about where things went wrong.

Challenge #2 Fixing Placement
=============================

With a sound plan in hand, it's much easier to fail to execute on it the
less material you have to execute with - so we gather up as many parts
as we can - as long as we think we can find them a better home.

Picking the right parts for gather is a black art - when you notice a
balance is slow it's because it's spending so much time iterating over
replica2part2dev trying to decide just the right parts to gather.

The replica plan can help at least in the gross dispersion collection to
gather up the worst offenders first before considering balance.  I think
trying to avoid picking up parts that are stuck to the tier before
falling into a forced grab on anything over parts_wanted helps with
stability generally - but depending on where the parts_wanted are in
relation to the full devices it's pretty easy pick up something that'll
end up really close to where it started.

I tried to break the gather methods into smaller pieces so it looked
like I knew what I was doing.

Going with a MAXIMUM gather iteration instead of balance (which doesn't
reflect the replica_plan) doesn't seem to be costing me anything - most
of the time the exit condition is either solved or all the parts overly
aggressively locked up on min_part_hours.  So far, it mostly seemds if
the thing is going to balance this round it'll get it in the first
couple of shakes.

Challenge #3 Crazy replica2part2dev tables
==========================================

I think there's lots of ways "scars" can build up a ring which can
result in very particular replica2part2dev tables that are physically
difficult to dig out of.  It's repairing these scars that will take
multiple rebalances to resolve.

... but at this point ...

... lacking a counter example ...

I've been able to close up all the edge cases I was able to find.  It
may not be quick, but progress will be made.

Basically my strategy just required a better understanding of how
previous algorithms were able to *mostly* keep things moving by brute
forcing the whole mess with a bunch of randomness.  Then when we detect
our "elegant" careful part selection isn't making progress - we can fall
back to same old tricks.

Validation
==========

We validate against duplicate part replica assignment after rebalance
and raise an ERROR if we detect more than one replica of a part assigned
to the same device.

In order to meet that requirement we have to have as many devices as
replicas, so attempting to rebalance with too few devices w/o changing
your replica_count is also an ERROR not a warning.

Random Thoughts
===============

As usual with rings, the test diff can be hard to reason about -
hopefully I've added enough comments to assure future me that these
assertions make sense.

Despite being a large rewrite of a lot of important code, the existing
code is known to have failed us.  This change fixes a critical bug that's
trivial to reproduce in a critical component of the system.

There's probably a bunch of error messages and exit status stuff that's
not as helpful as it could be considering the new behaviors.

Change-Id: I1bbe7be38806fc1c8b9181a722933c18a6c76e05
Closes-Bug: #1452431

Project: openstack/nova  a9459d3c41fa28dbbdac01d058d4a45e78906f7c

remove alembic from requirements.txt

Alembic was used in attempt #1 of online schema migrations, however
that was reverted in Icae28ceee3ec975c907d73b95babab58dcb30c23 when
that approach was dropped.

There are no other uses of alembic directly in Nova, so we should not
list this requirement.

Change-Id: I452bfc8454aedff1bbaffacc99d0845186ba4234

Project: openstack-infra/project-config  2e2d8519e3f9b2d8f9ce1330c6a0f8028c9e7c3f

Step #1 - Shutting down Nova-Docker

We are asking folks to evaluate Zun which has some of
the use cases from nova-docker. Several emails have been
sent to -dev@ and -operators@ many times over the last
two years.

Change-Id: I7adcc29cac151ec55f6cc322a880189e0e827db1

Project: openstack/glance  327682e8528bf4effa6fb16e8cabf744f18a55a1

Fix incompatibilities with WebOb 1.7

WebOb 1.7 changed [0] how request bodies are determined to be
readable. Prior to version 1.7, the following is how WebOb
determined if a request body is readable:
  #1 Request method is one of POST, PUT or PATCH
  #2 ``content_length`` length is set
  #3 Special flag ``webob.is_body_readable`` is set

The special flag ``webob.is_body_readable`` was used to signal
WebOb to consider a request body readable despite the content length
not being set. #1 above is how ``chunked`` Transfer Encoding was
supported implicitly in WebOb < 1.7.

Now with WebOb 1.7, a request body is considered readable only if
``content_length`` is set and it's non-zero [1]. So, we are only left
with #2 and #3 now. This drops implicit support for ``chunked``
Transfer Encoding Glance relied on. Hence, to emulate #1, Glance must
set the the special flag upon checking the HTTP methods that may have
bodies. This is precisely what this patch attemps to do.

[0] Pylons/webob#283
[1] https://github.com/Pylons/webob/pull/283/files#diff-706d71e82f473a3b61d95c2c0d833b60R894

Closes-bug: #1657459
Closes-bug: #1657452
Co-Authored-By: Hemanth Makkapati <hemanth.makkapati@rackspace.com>
Change-Id: I19f15165a3d664d5f3a361f29ad7000ba2465a85

Project: openstack/glance  327682e8528bf4effa6fb16e8cabf744f18a55a1

Fix incompatibilities with WebOb 1.7

WebOb 1.7 changed [0] how request bodies are determined to be
readable. Prior to version 1.7, the following is how WebOb
determined if a request body is readable:
  #1 Request method is one of POST, PUT or PATCH
  #2 ``content_length`` length is set
  #3 Special flag ``webob.is_body_readable`` is set

The special flag ``webob.is_body_readable`` was used to signal
WebOb to consider a request body readable despite the content length
not being set. #1 above is how ``chunked`` Transfer Encoding was
supported implicitly in WebOb < 1.7.

Now with WebOb 1.7, a request body is considered readable only if
``content_length`` is set and it's non-zero [1]. So, we are only left
with #2 and #3 now. This drops implicit support for ``chunked``
Transfer Encoding Glance relied on. Hence, to emulate #1, Glance must
set the the special flag upon checking the HTTP methods that may have
bodies. This is precisely what this patch attemps to do.

[0] Pylons/webob#283
[1] https://github.com/Pylons/webob/pull/283/files#diff-706d71e82f473a3b61d95c2c0d833b60R894

Closes-bug: #1657459
Closes-bug: #1657452
Co-Authored-By: Hemanth Makkapati <hemanth.makkapati@rackspace.com>
Change-Id: I19f15165a3d664d5f3a361f29ad7000ba2465a85

Project: openstack/nova  ba9a42e1ac68297a86dc1118e889ad66973c7dc6

PowerVM Driver: spawn/delete #1: no-ops

Initial change set introducing the PowerVM compute driver.  This change
set supplies the basic ComputeDriver methods to allow the n-cpu process
to start successfully; and no-op spawn & delete methods.

Subsequent change sets will build up to the functional spawn & delete
support found in https://review.openstack.org/#/c/391288

Change-Id: Ic45bb064f4315ea9e63698a7c0e541c5b0de5051
Partially-Implements: blueprint powervm-nova-compute-driver

Project: openstack/neutron  528ec277c373dd2e7f862cdd5a501cc03be878c4

remove and shim callbacks

The callback modules have been available in neutron-lib since commit [1]
and are ready for consumption.

As the callback registry is implemented with a singleton manager
instance, sync complications can arise ensuring all consumers switch to
lib's implementation at the same time. Therefore this consumption has
been broken down:
1) Shim neutron's callbacks using lib's callback system and remove
existing neutron internals related to callbacks (devref, UTs, etc.).
2) Switch all neutron's callback imports over to neutron-lib's.
3) Have all sub-projects using callbacks move their imports over to use
neutron-lib's callbacks implementation.
4) Remove the callback shims in neutron-lib once sub-projects are moved
over to lib's callbacks.
5) Follow-on patches moving our existing uses of callbacks to the new
event payload model provided by neutron-lib.callback.events

This patch implements #1 from above, shimming neutron's callbacks and
removing devref + UTs. Rather than shimming using debtcollector, this
patch leaves callback constants as-is, and simply references the lib
class/function in its respective neutron callback module. This allows
consumers to test callback types without changing code. For example,
an except block block like that below continues to work even though
the raised exception now lives in lib::

try:
     neutron_cb_registry.notify(...)
except neutron_cb_exceptions.CallbackFailure:
     handle_exception()

In addition this patch contains minor UT updates to support the shim
approach.

NeutronLibImpact

[1] fea8bb64ba7ff52632c2bd3e3298eaedf623ee4f

Change-Id: Ib6baee2aaeb044aaba42a97b35900d75dd43021f

Project: openstack/neutron  5d98e30e5c45e3bda70645c7dfc490d5a9deba76

fix formatting in ubuntu controller install guide

The ubuntu controller install guide contains improper indentation and
extraneous new lines. As a result the sub-steps for #1 are not shown
in this HTML (generated) guide.

This one needs to also get back-ported to pike.

Change-Id: Ib2b263c8da49ccc8905cbd59331ce6694de232e6
Closes-Bug: #1712107

* Update zun from branch 'master'
  - Merge "Pull image from registry"
  - Pull image from registry
    
    This commit complete the support of private docker registry.
    Users can create a container with images from a specified
    docker registry. The steps are as following:
    
    1. Registry a docker registry in Zun (with options to specify
       the username/password to authenticate against the registry).
    2. Run a container with a reference to the registry created in #1.
    
    Closes-Bug: #1702830
    Change-Id: I92f73bf0d759d9e770905debc6f40a5697ef0856

* Update kuryr-kubernetes from branch 'master'
  - Set MAC address for VF via netlink message to PF
    
    SR-IOV binding driver uses pyroute2 library to set MAC addresses
    to VFs. This is internally implemented via ioctl(SIOCSIFHWADDR)
    giving it the name of that device. This is equal to calling
    'ip link set dev $VFDEV address $MAC'. However, there is another
    way to set MAC address for VF. It works via netlink RTM_SETLINK
    message to the PF. This is equal to calling
    'ip link set dev $PFDEV vf $VFID mac $MAC'.
    
    How it works:
    * ioctl(SIOCSIFHWADDR) asks the VF driver to set the MAC
      --> VF driver asks PF to set MAC for it
      --> PF sets the MAC for VF.
    * RTM_SETLINK message asks the PF to set MAC for VF
      --> PF sets the MAC for VF.
    
    In case of setting directly via PF, PF additionally sets an
    "administratively changed MAC" flag for that VF in the PF's
    driver, and from that point on (until the PF's driver is
    reloaded) that VF's MAC address can't be changed using the
    method #1.
    
    It's a security feature designed to forbid MAC changing by the
    guest OS/app inside the container.
    
    Above leads to the issue where SR-IOV CNI is not able to set MAC
    address for VF if its MAC was previously administratively set at
    least once (by hands or other software):
    
      ioctl SIOCSIFHWADDR: Cannot assign requested address
    
      kernel: igb 0000:05:00.0:
        VF 0 attempted to override administratively set MAC address
        Reload the VF driver to resume operations
    
    After that CNI fails the whole transaction, i.e. fails to change
    the interface name as well and subsequently fails the binding.
    
    Netlink PF method to change MAC addresses should be used always.
    This will additionally forbid the MAC changing from the inside
    of container.
    
    Change-Id: Ic47672e4ce645d9d37b520b6a412a44ae61036e1
    Closes-Bug: 1825383
    Co-authored-by: Danil Golov <d.golov@samsung.com>
    Signed-off-by: Ilya Maximets <i.maximets@samsung.com>

* Update neutron from branch 'master'
  - Merge "doc: remove deprecated [neutron]/url from compute install guide"
  - doc: remove deprecated [neutron]/url from compute install guide
    
    The nova [neutron]/url config option was deprecated in Queens [1]
    and is being removed in Train [2]. The neutron install guide
    sections about configuring compute to work with neutron were still
    using the url option so this change removes them. There are a few
    things to note here:
    
    1. The url option functionality is replaced with the endpoint_override
       option from keystoneauth1 but we don't really want users using that
       unless there is a real need. One of the main reasons for moving the
       nova configuration to use keystoneauth1 was so that the network
       service endpoint can be looked up via KSA dynamically based on the
       configurable interfaces (public, internal, private) and service types
       authority so the endpoint URL will just be pulled from the service
       catalog. That means not having to hard-code the endpoint URL in nova
       config which makes deployment and config management simpler. As such,
       the url option removed in the install guide here is not replaced with
       the endpoint_override option.
    
    2. Following on #1, the install guide portion about the nova/neutron config
       is updated with a link back to the nova config guide for the full set
       of options in case an operator needs to tweak the config, e.g. to set
       valid_interfaces or endpoint_override because the KSA defaults don't work
       for their deployment.
    
    3. With the old url option, if region_name was not specified, nova would
       default to 'RegionOne'. That is not the case if not using the url option
       so we leave the region_one config in the install guide example, otherwise
       region_name would default to None.
    
    [1] I41724a612a5f3eabd504f3eaa9d2f9d141ca3f69
    [2] I6c068a84c4c0bd88f088f9328d7897bfc1f843f1
    
    Change-Id: I30445edeb8509330571db28c7d61dd63886e9e61
    Closes-Bug: #1840930

* Update kolla-ansible from branch 'master'
  - Merge "Limit open file descriptors for Neutron agent containers"
  - Limit open file descriptors for Neutron agent containers
    
    See https://bugs.launchpad.net/oslo.rootwrap/+bug/1760471, in particular
    comment #1 for an explanation of why inheriting the defaults of the
    docker daemon can cause poor performance:
    
    The performance difference likely comes from close_fds=True of subprocess.
    Popen. On Python 2, Popen calls close(fd) on all file descriptors from 3 to
    SC_OPEN_MAX. On my Fedora 27 "host", SC_OPEN_MAX is 1,024. But in docker,
    SC_OPEN_MAX is... 1,048,576: 1,000x larger. On Python 3, Popen is smarter. On
    Linux, it lists the content of /proc/self/fd/ to only close open file
    descriptors. It doesn't depend on SC_OPEN_MAX value.
    
    Change-Id: Iefef6039644192420abbd3bf614329cbc0d9a62a
    Closes-Bug: #1848737
    Related-Bug: #1760471
    Related-Bug: #1757556
    Related-Bug: #1824020

* Update tripleo-heat-templates from branch 'master'
  - Merge "Fix pcs restart in composable HA"
  - Fix pcs restart in composable HA
    
    When a redeploy command is being run in a composable HA environment, if there
    are any configuration changes, the <bundle>_restart containers will be kicked
    off. These restart containers will then try and restart the bundles globally in
    the cluster.
    
    These restarts will be fired off in parallel from different nodes. So
    haproxy-bundle will be restarted from controller-0, mysql-bundle from
    database-0, rabbitmq-bundle from messaging-0.
    
    This has proven to be problematic and very often (rhbz#1868113) it would fail
    the redeploy with:
    2020-08-11T13:40:25.996896822+00:00 stderr F Error: Could not complete shutdown of rabbitmq-bundle, 1 resources remaining
    2020-08-11T13:40:25.996896822+00:00 stderr F Error performing operation: Timer expired
    2020-08-11T13:40:25.996896822+00:00 stderr F Set 'rabbitmq-bundle' option: id=rabbitmq-bundle-meta_attributes-target-role set=rabbitmq-bundle-meta_attributes name=target-role value=stopped
    2020-08-11T13:40:25.996896822+00:00 stderr F Waiting for 2 resources to stop:
    2020-08-11T13:40:25.996896822+00:00 stderr F * galera-bundle
    2020-08-11T13:40:25.996896822+00:00 stderr F * rabbitmq-bundle
    2020-08-11T13:40:25.996896822+00:00 stderr F * galera-bundle
    2020-08-11T13:40:25.996896822+00:00 stderr F Deleted 'rabbitmq-bundle' option: id=rabbitmq-bundle-meta_attributes-target-role name=target-role
    2020-08-11T13:40:25.996896822+00:00 stderr F
    
    or
    
    2020-08-11T13:39:49.197487180+00:00 stderr F Waiting for 2 resources to start again:
    2020-08-11T13:39:49.197487180+00:00 stderr F * galera-bundle
    2020-08-11T13:39:49.197487180+00:00 stderr F * rabbitmq-bundle
    2020-08-11T13:39:49.197487180+00:00 stderr F Could not complete restart of galera-bundle, 1 resources remaining
    2020-08-11T13:39:49.197487180+00:00 stderr F * rabbitmq-bundle
    2020-08-11T13:39:49.197487180+00:00 stderr F
    
    After discussing it with kgaillot it seems that concurrent restarts in pcmk are just brittle:
    """
    Sadly restarts are brittle, and they do in fact assume that nothing else is causing resources to start or stop. They work like this:
    
    - Get the current configuration and state of the cluster, including a list of active resources (list #1)
    - Set resource target-role to Stopped
    - Get the current configuration and state of the cluster, including a list of which resources *should* be active (list #2)
    - Compare lists #1 and #2, and the difference is the resources that should stop
    - Periodically refresh the configuration and state until the list of active resources matches list #2
    - Delete the target-role
    - Periodically refresh the configuration and state until the list of active resources matches list #1
    """
    
    So the suggestion is to replace the restarts with an enable/disable cycle of the resource.
    
    Tested this on a dozen runs on a composable HA environment and did not observe the error
    any longer.
    
    Closes-Bug: #1892206
    
    Change-Id: I9cc27b1539a62a88fb0bccac64e6b1ae9295f22e

* Update tripleo-heat-templates from branch 'master'
  to fac82416f06ec89ce3fd71cf373a92016e91d0b2
  - Merge "Expose additional network sysctl knobs"
  - Expose additional network sysctl knobs
    
    For BGP we need to expose a few additional sysctl entries.
    Namely we need net.ipv4.conf.all.rp_filter and
    net.ipv6.conf.all.forwarding. Let's expose them like
    the other ones via the KernelIpv4ConfAllRpFilter and
    KernelIpv6ConfAllForwarding heat parameters, respectively.
    
    We set KernelIpv4ConfAllRpFilter to a default of 1 as that is
    what is the default with RHEL >= 6
    (https://access.redhat.com/solutions/53031)
    
    We set KernelIpv6ConfAllForwarding to a default of 0 since that is
    the default with at least RHEL >= 7.
    
    Verified the defaults on RHEL/CentOS-7:
    $ uname -a
    Linux rhel-7.redhat.local 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Mar 25 21:21:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
    $ cat /proc/sys/net/ipv4/conf/all/rp_filter /proc/sys/net/ipv6/conf/all/forwarding
    1
    0
    
    and RHEL/CentOS-8:
    $ uname -a
    Linux localhost 4.18.0-293.el8.x86_64 #1 SMP Mon Mar 1 10:04:09 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
    $ cat /proc/sys/net/ipv4/conf/all/rp_filter /proc/sys/net/ipv6/conf/all/forwarding
    1
    0
    
    Co-Authored-By: Carlos Gonçalves <cgoncalves@redhat.com>
    
    Change-Id: I6d7d598e374cdc5289a61a7fb6b532c80a714458

* Update ironic-python-agent from branch 'master'
  to 9837f1c2f008d7e02dbf14f20f520c70e1281477
  - Merge "Fix NVMe Partition image on UEFI"
  - Fix NVMe Partition image on UEFI
    
    The _manage_uefi code has a check where it attempts to just
    identify the precise partition number of the device, in order
    for configuration to be parsed and passed. However, the same code
    did not handle the existence of a `p1` partition instead of just a
    partition #1. This is because the device naming format is different
    with NVMe and Software RAID.
    
    Likely, this wasn't an issue with software raid due to how complex the
    code interaction is, but the docs also indicate to use only whole disk
    images in that case.
    
    This patch was pulled down my one RH's professional services folks
    who has confirmed it does indeed fix the issue at hand. This is noted
    as a public comment on the Red Hat bugzilla.
    https://bugzilla.redhat.com/show_bug.cgi?id=1954096
    
    Story: 2008881
    Task: 42426
    Related: rhbz#1954096
    Change-Id: Ie3bd49add9a57fabbcdcbae4b73309066b620d02

* Update designate-tempest-plugin from branch 'master'
  to 3675bd53b0894903abf47e768bb045160c687284
  - Merge "New API test cases for a Zone test suite."
  - New API test cases for a Zone test suite.
    
    "test_get_primary_zone_nameservers"
    1) Create a PRIMARY Zone
    2) Retrive Zone Name Servers and validate that not empty
    3) Get zone's "pool_id"
    3) Make sure that the zone's Name Servers retrieved in #2
    are the same as created in zone'a pool.
    
    "test_create_zones" scenario"
    1) Create PRIMARY zone and validate the creation
    2) Get the Name Servers created in PRIMARY zone and extract hosts list.
       Hosts list is used to provide "masters" on SECONDARY zone creation
    3) Create a SECONDARY zone and validate the creation
      # Note: the existing test was modified to cover both types:
        PRIMARY and SECONDARY
    
    "test_manually_trigger_update_secondary_zone_negative"
    1) Create a Primary zone
    2) Get the nameservers created in #1 and make sure that
       those nameservers are not available (pingable)
    3) Create a secondary zone
    4) Manually trigger zone update and make sure that
       the API fails with status code 500 as Nameservers aren’t available.
    
    "test_zone_abandon"
    1) Create a zone
    2) Show a zone
    3) Make sure that the created zone is in: Nameserver/BIND
    4) Abandon a zone
    5) Wait till a zone is removed from the Designate DB
    6) Make sure that the zone is still in Nameserver/BIND
    
    "test_zone_abandon_forbidden"
    1) Create a zone
    2) Show a zone
    3) Make sure that the created zone is in: Nameserver/BIND
    4) Abandon a zone as primary tenant (not admin)
    5) Make sure that the API fails with: "403 Forbidden"
    
    Change-Id: I6df991145b1a3a2e4e1d402dd31204a67fb45a11

* Update kuryr-kubernetes from branch 'master'
  to b7e87c94b1a9af467806c297975b80cd8ff40de1
  - Merge "Pools: Fix order of updated SGs"
  - Pools: Fix order of updated SGs
    
    According to the comments in vif_pool.py, if there are no ports in the
    pool with the requested SG set, we should update the SG on another port,
    starting from the ones that were created soonest. I think this logic is
    to make sure we grab the ports with most outdated SGs. Anyway that code
    is currently broken because of two issues:
    
    1. _last_update dict is always updated by replacing whole dict,
       basically meaning that it's only holding data for SG that got updated
       most recently.
    2. There's a race condition where in _get_port_from_pool multiple
       threads can steal a port from themselves.
    
    This commit solves #2 by switching to use OrderedDict to track which SG
    is the one that was used most recently. This way we can just iterate the
    OrderDict when choosing which port should get its SG updated and just
    choose the next port if we get IndexError on pop(). This also solves #1
    because _last_update is no longer used to decide which ports have the
    most outdated SGs.
    
    Change-Id: Ia3159ee007be865db404e2dcef688abe21592553

* Update devstack from branch 'master'
  to 9eb64896dd785b96b191ce939396420f592e53b4
  - Merge "Use proper sed separator for paths"
  - Use proper sed separator for paths
    
    I941ef5ea90970a0901236afe81c551aaf24ac1d8 added a sed command that
    should match and delete path values but used '/' as sed separator. This
    leads to error in unstack.sh runs when the path also contains '/':
    
    +./unstack.sh:main:188 sudo sed -i '/directory=/opt/stack/ d' /etc/gitconfig
    sed: -e expression #1, char 13: unknown command: `o'
    
    So this patch replace '/' separator with '+'.
    
    Change-Id: I06811c0d9ee7ecddf84ef1c6dd6cff5129dbf4b1

* Update neutron-tempest-plugin from branch 'master'
  to 7b2f5c38a1b5483c0cb8a767e74ae12e3df6c63b
  - Merge "Add a test for removing security group from ACTIVE instance"
  - Add a test for removing security group from ACTIVE instance
    
    Test name: "test_remove_sec_grp_from_active_vm"
    1) Create SG associated with ICMP rule
    2) Create Port (assoiated to SG #1) and use it to create the VM
    3) Ping the VM, expected should be PASS
    4) Remove the security group from VM by Port update
    5) Ping the VM, expected should be FAIL
    
    Change-Id: I9fbcdd0f30beeb6985bab4de4d53af639f408c75

* Update tooz from branch 'master'
  to 1e86b9103584ce4360633df8e9c536a559a1f79b
  - Merge "Fix inappropriate logic in memcachedlock.release()"
  - Fix inappropriate logic in memcachedlock.release()
    
    Whether 'was_deleted' was 'TRUE' or not, eventually we have to remove
    self from '_acquired_locks'.
    For example:
    1. App #1 with coordinator 'A' wants to release lock "b"
    2. 'self.coord.client.delete()' failed for some reason(.e.g,
    BrokenPipeError,MemcacheUnexpectedCloseError)
    3. According to the former logic,lock "b" will not remove
    from "_acquired_locks", so "self.heartbeat()" will make it alive
    forever until App #1 was down or lock "b" turned expired.
    4. Now App #1 with coordinator 'A' wants to acquire lock "c", who
    have the same lock-name with lock "b",It is clear that this will
    fail and prevent the locked program from continuing to execute.
    
    Change-Id: I6fc33b8e0a88510027bcfc30d1504489d2a91b4e

* Update nova from branch 'master'
  to ccc06ac808458e009b9bee3cf8cdd43242204920
  - Merge "Trigger reschedule if PCI consumption fail on compute"
  - Trigger reschedule if PCI consumption fail on compute
    
    The PciPassthroughFilter logic checks each InstancePCIRequest
    individually against the available PCI pools of a given host and given
    boot request. So it is possible that the scheduler accepts a host that
    has a single PCI device available even if two devices are requested for
    a single instance via two separate PCI aliases. Then the PCI claim on
    the compute detects this but does not stop the boot just logs an ERROR.
    This results in the instance booted without any PCI device.
    
    This patch does two things:
    1) changes the PCI claim to fail with an exception and trigger a
       re-schedule instead of just logging an ERROR.
    2) change the PciDeviceStats.support_requests that is called during
       scheduling to not just filter pools for individual requests but also
       consume the request from the pool within the scope of a single boot
       request.
    
    The fix in #2) would not be enough alone as two parallel scheduling
    request could race for a single device on the same host. #1) is the
    ultimate place where we consume devices under a compute global lock so
    we need the fix there too.
    
    Closes-Bug: #1986838
    Change-Id: Iea477be57ae4e95dfc03acc9368f31d4be895343

* Update tripleo-ci from branch 'master'
  to a860a16e9313a7c0e8862af69ec4d94942a30721
  - Mark tripleo-ci-centos-8-9-multinode-mixed-os non voting
    
    This is temporary as described in related-bug (see comment #1)
    
    Related-Bug: 1989341
    Change-Id: I6587573bbfccdb4d83b1bae3364fc51ef4615bbb

* Update nova from branch 'master'
  to 8b4104f9f78d0615720c0ba1e3e8cfced42efcc5
  - Merge "Split PCI pools per PF"
  - Split PCI pools per PF
    
    Each PCI device and each PF is a separate RP in Placement and the
    scheduler allocate them specifically so the PCI filtering and claiming
    also needs to handle these devices individually. Nova pooled PCI devices
    together if they had the same device_spec and same device type and numa
    node. Now this is changed that only pool VFs from the same parent PF.
    Fortunately nova already handled consuming devices for a single
    InstancePCIRequest from multiple PCI pools, so this change does not
    affect the device consumption code path.
    
    The test_live_migrate_server_with_neutron test needed to be changed.
    Originally this test used a compute with the following config:
    * PF 81.00.0
    ** VFs 81.00.[1-4]
    * PF 81.01.0
    ** VFs 81.01.[1-4]
    * PF 82.00.0
    
    And booted a VM that needed one VF and one PF. This request has two
    widely different solutions:
    1) allocate the VF from under 81.00 and therefore consume 81.00.0 and
       allocate the 82.00.0 PF
       This was what the test asserted to happen.
    2) allocate the VF from under 81.00 and therefore consume 81.00.0 and
       allocate the 81.00.0 PF and therefore consume all the VFs under it
       This results in a different amount of free devices than #1)
    
    AFAIK nova does not have any implemented preference for consuming PFs
    without VFs. The test just worked by chance (some internal device and
    pool ordering made it that way). However when the PCI pools are split
    nova started choosing solution #2) making the test fail. As both
    solution is equally good from nova's scheduling contract perspective I
    don't consider this as a behavior change. Therefore the test is updated
    not to create a situation where two different scheduling solutions are
    possible.
    
    blueprint: pci-device-tracking-in-placement
    Change-Id: I4b67cca3807fbda9e9b07b220a28e331def57624

* Update ironic from branch 'master'
  to 81e10265ce08bd525388111720b91ca10c99bb28
  - Merge "Use association_proxy for ports node_uuid"
  - Use association_proxy for ports node_uuid
    
    This change adds 'node_uuid' to ironic.objects.port.Port
    and adds a relationship using association_proxy in
    models.Port. Using the association_proxy removes the need
    to do the node lookup to populate node uuid for ports in
    the api controller.
    
    NOTE:
     On port create a read is added to read the port from the
     database, this ensures node_uuid is loaded and solves the
     DetachedInstanceError which is otherwise raised.
    
    Bumps Port object version to 1.11
    
    With patch:
      1. Returned 20000 ports in python 2.7768702507019043
         seconds from the DB.
      2. Took 0.433107852935791 seconds to iterate through
         20000 port objects.
         Ports table is roughly 12800000 bytes of JSON.
      3. Took 5.662816762924194 seconds to return all 20000
         ports via ports API call pattern.
    
    Without patch:
      1. Returned 20000 ports in python 1.0273635387420654
         seconds from the DB.
      2. Took 0.4772777557373047 seconds to iterate through
         20000 port objects.
         Ports table is roughly 12800000 bytes of JSON.
      3. Took 147.8800814151764 seconds to return all 20000
         ports via ports API call pattern.
    
    Conclusion:
      Test #1 plain dbapi.get_port_list() test is ~3 times
      slower, but Test #3 doing the API call pattern test
      is ~2500% better.
    
    Story: 2007789
    Task: 40035
    Change-Id: Iff204b3056f3058f795f05dc1d240f494d60672a