diff --git a/doc/source/contributor/code-reviews.rst b/doc/source/contributor/code-reviews.rst index 5fee74a1d6..30a42c05eb 100644 --- a/doc/source/contributor/code-reviews.rst +++ b/doc/source/contributor/code-reviews.rst @@ -18,26 +18,55 @@ 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 ------------------------ @@ -45,3 +74,12 @@ 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. diff --git a/doc/source/contributor/release-management.rst b/doc/source/contributor/release-management.rst index 91f483e38c..b00f8dd226 100644 --- a/doc/source/contributor/release-management.rst +++ b/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 diff --git a/docker/neutron/neutron-infoblox-ipam-agent/Dockerfile.j2 b/docker/neutron/neutron-infoblox-ipam-agent/Dockerfile.j2 deleted file mode 100644 index a27b7cdd09..0000000000 --- a/docker/neutron/neutron-infoblox-ipam-agent/Dockerfile.j2 +++ /dev/null @@ -1,20 +0,0 @@ -FROM {{ namespace }}/{{ image_prefix }}neutron-server:{{ tag }} -{% block labels %} -LABEL maintainer="{{ maintainer }}" name="{{ image_name }}" build-date="{{ build_date }}" -{% endblock %} - -# This image inherits from neutron-server image, which is also a leaf image, -# and therefore sets the user to neutron. Set the user to root, so that any -# headers or footers used have the right context. -USER root - -{% block neutron_infoblox_ipam_agent_header %}{% endblock %} - -{% import "macros.j2" as macros with context %} - -{{ macros.kolla_patch_sources() }} - -{% block neutron_infoblox_ipam_agent_footer %}{% endblock %} -{% block footer %}{% endblock %} - -USER neutron diff --git a/kolla/common/config.py b/kolla/common/config.py index 7657ed485e..8a80e1f88f 100644 --- a/kolla/common/config.py +++ b/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('-', '/') diff --git a/releasenotes/notes/align-default-tag-with-kolla-ansible-7b2224d881848864.yaml b/releasenotes/notes/align-default-tag-with-kolla-ansible-7b2224d881848864.yaml new file mode 100644 index 0000000000..3d0339b364 --- /dev/null +++ b/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 ``--``, 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. diff --git a/releasenotes/notes/remove-networking-infoblox-d2819f908d7d2b54.yaml b/releasenotes/notes/remove-networking-infoblox-d2819f908d7d2b54.yaml new file mode 100644 index 0000000000..2fb77a185c --- /dev/null +++ b/releasenotes/notes/remove-networking-infoblox-d2819f908d7d2b54.yaml @@ -0,0 +1,4 @@ +--- +upgrade: + - | + The ``neutron-infoblox-ipam-agent`` image has been removed. diff --git a/roles/kolla-build-config/defaults/main.yml b/roles/kolla-build-config/defaults/main.yml index 0306bb0cf7..f00b611902 100644 --- a/roles/kolla-build-config/defaults/main.yml +++ b/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