Synchronise master with upstream

doc/source/contributor/code-reviews.rst

@@ -18,30 +18,68 @@ The volume of emails is not too large if you subscribe to *New Changes* only.
 If you do not have much time available for reviewing, consider reviewing
 patches in an area that is important to you or that you understand well.
 
-Core reviewers
-==============
+Core reviewer groups
+====================
 
-Core reviewers have additional labels available to them.
+There are two core reviewer groups in the Kolla project, each with different
+levels of access.
+
+kolla-core
+----------
+
+Members of ``kolla-core`` have the following additional labels available:
 
 * +2: Approve
 * -2: Do not merge
 * Workflow +1: Approve and ready for merge
 
 Zuul requires one +2 and one workflow +1, as well as a passing check, in order
-for a patch to proceed to the gate. The Kolla team generally requires two +2s
-before a workflow +1 may be added. We also have some non-voting Zuul jobs which
-will not block a check, but should be investigated if they are failing.
+for a patch to proceed to the gate.
+
+We also have some non-voting Zuul jobs which will not block a check, but should
+be investigated if they are failing.
+
+The Kolla project generally requires two +2s before a workflow +1 may be added.
+Exceptions where a single +2 is sufficient before adding workflow +1 are:
 
-Core reviewers may still use +1 to indicate approval if they are not confident
-enough about a particular patch to use +2.
+* CI-only patches
+* Documentation patches
+* Trivial patches
 
-The Kolla core reviewers have the same rights of access to stable branches, so
+``kolla-core`` members may still use +1 to indicate approval if they are not
+confident enough about a particular patch to use +2.
+
+``kolla-core`` members have the same rights of access to stable branches, so
 always check the branch for a review, and use extra care with stable branches.
 
+kolla-reviewers
+---------------
+
+Members of ``kolla-reviewers`` have the following additional labels available:
+
+* +2: Approve
+* -2: Do not merge
+
+``kolla-reviewers`` members do not have workflow rights and cannot approve a
+patch for merging. Their +2 counts toward the two +2s required before a
+``kolla-core`` member may add a workflow +1.
+
+``kolla-reviewers`` members may still use +1 to indicate approval if they are
+not confident enough about a particular patch to use +2.
+
 Becoming a core reviewer
 ------------------------
 
 There are no strict rules for becoming a core reviewer. Join the community,
 review some patches, and demonstrate responsibility, understanding & care. If
 you are interested in joining the core team, ask the PTL or another core
 reviewer how to get there.
+
+Stale patches
+=============
+
+If a reviewed patch has received no response from its owner for two weeks, it
+is at the discretion and motivation of the core reviewers to update and carry
+that patch forward if they deem it valuable for the upcoming release. In that
+case, the core reviewer taking ownership of the patch should add their own
+DCO signoff (``Signed-off-by:``) to the commit message.

doc/source/contributor/release-management.rst

@@ -115,10 +115,7 @@ build and deploy the previous release of OpenStack projects, as described in
 * [kayobe] Switch ``openstack_release`` and ``override_checkout`` in Kayobe
   master branch to use the master branch of dependencies.
 
-  .. note:: The IPA image still needs to use the previous release in order to
-            be compatible with Ironic.
-
-  * example: https://review.opendev.org/c/openstack/kayobe/+/791764
+  * example: https://review.opendev.org/c/openstack/kayobe/+/950512
 
 * [all] Search for TODOs/FIXMEs/NOTEs in the codebases describing tasks to be
   performed during the new release cycle

kolla/common/config.py

@@ -211,7 +211,7 @@
                help=('The number of threads to use while building.'
                      ' (Note: setting to one will allow real time'
                      ' logging)')),
-    cfg.StrOpt('tag', default=version.cached_version_string(),
+    cfg.StrOpt('tag',
                help='The container image tag'),
     cfg.BoolOpt('template-only', default=False,
                 help="Don't build images. Generate Dockerfile only"),
@@ -378,6 +378,8 @@ def parse(conf, args, usage=None, prog=None,
     # NOTE(jeffrey4l): set the default base tag based on the
     # base option
     conf.set_default('base_tag', DEFAULT_BASE_TAGS[conf.base]['tag'])
+    conf.set_default('tag',
+                     f"{conf.openstack_release}-{conf.base}-{conf.base_tag}")
     prefix = '' if conf.openstack_release == 'master' else 'stable-'
     openstack_branch = '{}{}'.format(prefix, conf.openstack_release)
     openstack_branch_slashed = openstack_branch.replace('-', '/')

releasenotes/notes/align-default-tag-with-kolla-ansible-7b2224d881848864.yaml

@@ -0,0 +1,9 @@
+---
+upgrade:
+  - |
+    The default value of the ``tag`` option has changed. Previously it
+    defaulted to the Kolla version string. It now defaults to a composite
+    value of ``<openstack_release>-<base>-<base_tag>``, aligning with the
+    convention used by Kolla-Ansible. Users who relied on the implicit
+    version-based tag should set ``--tag`` explicitly to preserve the old
+    behaviour.

releasenotes/notes/remove-networking-infoblox-d2819f908d7d2b54.yaml

@@ -0,0 +1,4 @@
+---
+upgrade:
+  - |
+    The ``neutron-infoblox-ipam-agent`` image has been removed.

roles/kolla-build-config/defaults/main.yml

@@ -41,7 +41,6 @@ kolla_build_sources:
   openstack/neutron-dynamic-routing:
     - neutron-bgp-dragent
     - neutron-server-plugin-neutron-dynamic-routing
-  openstack/networking-infoblox: neutron-server-plugin-networking-infoblox
   openstack/networking-generic-switch: neutron-base-plugin-networking-generic-switch
   openstack/networking-sfc:
     - neutron-base-plugin-networking-sfc