Merge "Remove the tags framework (part 1)"

doc/source/_exts/badges.py

@@ -28,7 +28,6 @@ LOG = logging.getLogger(__name__)
 NUM_COL = 4
 PADDING = 8
 BADGE_SPACING = 4
-BASE_TAGS_URL = 'https://governance.openstack.org/tc/reference/tags/'
 COLOR_SCHEME = {
     "brightgreen": "#4c1",
     "green": "#97CA00",
@@ -124,27 +123,10 @@ def _get_base_badges():
     ]
 
 
-def _get_tag_badges(tags):
+def _organize_badges(base_badges):
-    badges = []
-
-    for tag in tags:
-        # NOTE(flaper87): will submit other patches to make these
-        # tags consistent with the rest.
-        if tag in ['starter-kit:compute']:
-            group, tname = 'tc', tag
-        else:
-            group, tname = tag.split(':')
-
-        link = BASE_TAGS_URL + '%s.html' % tag.replace(':', '_')
-        badges.append(_badge(group, tname, link, colorscheme='blue'))
-
-    return sorted(badges, key=lambda b: b['left_text']+b['right_text'])
-
-
-def _organize_badges(base_badges, tag_badges):
 
     # Arrange badges in NUM_COL columns, filling the rest with width=0 badges
-    ziped = list(zip_longest(*(iter(base_badges + tag_badges),) * NUM_COL,
+    ziped = list(zip_longest(*(iter(base_badges),) * NUM_COL,
                              fillvalue={'width': 0}))
 
     result = []
@@ -195,9 +177,7 @@ def _generate_teams_badges(app, exception=None):
         LOG.info('generating team badge for %s' % team)
 
         for name, deliverable in info['deliverables'].items():
-            tags = info.get('tags', []) + deliverable.get('tags', [])
+            badges = _organize_badges(_get_base_badges())
-            badges = _organize_badges(_get_base_badges(),
-                                      _get_tag_badges(tags))
             svg = '\n'.join(_to_svg(chain(*badges)))
             root_width = max([bdg_row[-1]['width'] + bdg_row[-1]['svg_x']
                               for bdg_row in badges])

doc/source/_exts/teams.py

@@ -109,14 +109,6 @@ def _team_to_rst(name, info):
         yield ''
         yield mission
         yield ''
-    tags = info.get('tags', [])
-    if tags:
-        yield 'Team-based tags'
-        yield '---------------'
-        yield ''
-        for tag in tags:
-            yield '- :ref:`tag-%s`' % tag
-        yield ''
     yield 'Deliverables'
     yield '------------'
     yield ''

goals/completed/stein/upgrade-checkers.rst

@@ -58,7 +58,7 @@ The command must:
    * 1 - Warning that one or issues were found that require investigation
    * 2 - One or more checks found an issue that will cause upgrade to fail
 
-#. Projects with the :ref:`tag-assert:supports-upgrade` tag must integrate
+#. Projects with the supports-upgrade tag must integrate
    their upgrade check command into their upgrade CI testing.
 
 .. note:: This goal is primarily focused on the traditional stateful service

openstack_governance/governance.py

@@ -24,17 +24,6 @@ LOG = logging.getLogger(__name__)
 REPO_URL_BASE = "https://opendev.org/openstack/governance/raw/branch/master"
 
 
-def get_tags_for_deliverable(team_data, team, name):
-    "Return the tags for the deliverable owned by the team."
-    if team not in team_data:
-        return set()
-    team_info = team_data[team]
-    dinfo = team_info['deliverables'].get(name)
-    if not dinfo:
-        return set()
-    return set(dinfo.get('tags', [])).union(set(team_info.get('tags', [])))
-
-
 class Team(object):
 
     def __init__(self, name, data):
@@ -54,10 +43,6 @@ class Team(object):
         }
         self.liaisons = data.get('liaisons', [])
 
-    @property
-    def tags(self):
-        return set(self.data.get('tags', []))
-
     @property
     def service(self):
         return self.data.get('service')
@@ -79,7 +64,7 @@ class Deliverable(object):
 
     @property
     def tags(self):
-        return set(self.data.get('tags', [])).union(self.team.tags)
+        return set(self.data.get('tags', []))
 
 
 class Repository(object):
@@ -87,10 +72,6 @@ class Repository(object):
         self.name = name
         self.deliverable = weakref.proxy(deliverable)
 
-    @property
-    def tags(self):
-        return self.deliverable.tags
-
 
 class Governance(object):
 
@@ -172,8 +153,7 @@ class Governance(object):
                     return team
         raise ValueError('Repository %s not found in governance list' % repo_name)
 
-    def get_repositories(self, team_name=None, deliverable_name=None,
+    def get_repositories(self, team_name=None, deliverable_name=None):
-                         tags=[]):
         """Return a sequence of repositories, possibly filtered.
 
         :param team_name: The name of the team owning the repositories. Can be
@@ -181,13 +161,8 @@ class Governance(object):
             or team_name='Technical Committee'
         :para deliverable_name: The name of the deliverable to which all
            repos should belong.
-        :param tags: The names of any tags the repositories should
-            have. Can be empty.
 
         """
-        if tags:
-            tags = set(tags)
-
         if team_name:
             teams = [self.get_team(team_name)]
         else:
@@ -202,6 +177,4 @@ class Governance(object):
                 deliverables = team.deliverables.values()
             for deliverable in deliverables:
                 for repository in deliverable.repositories.values():
-                    if tags and not tags.issubset(repository.tags):
-                        continue
                     yield repository

openstack_governance/projects_schema.yaml

@@ -116,10 +116,6 @@ additionalProperties:
               - external
           deprecated:
             type: "string"
-    tags:
-      type: "array"
-      items:
-        type: "string"
     extra-atcs:
       type: "array"
       items:

openstack_governance/tests/test_governance.py

@@ -50,8 +50,6 @@ Release Management:
       - name: Daniel Bengtsson
         irc: damani
         email: dbengt@redhat.com
-  tags:
-    - team:diverse-affiliation
   deliverables:
     release-schedule-generator:
       repos:
@@ -182,26 +180,6 @@ class TestGetRepositories(base.BaseTestCase):
             [r.name for r in repos],
         )
 
-    def test_tag_negative(self):
-        repos = self.gov.get_repositories(
-            tags=['team:single-vendor'],
-        )
-        self.assertEqual([], list(repos))
-
-    def test_tags_positive(self):
-        repos = self.gov.get_repositories(
-            tags=['team:diverse-affiliation'],
-        )
-        self.assertEqual(
-            sorted(['openstack/release-schedule-generator',
-                    'openstack/release-test',
-                    'openstack-infra/release-tools',
-                    'openstack/releases',
-                    'openstack/reno',
-                    'openstack-dev/specs-cookiecutter']),
-            sorted(r.name for r in repos),
-        )
-
 
 class TestGetTeam(base.BaseTestCase):
 

reference/house-rules.rst

@@ -89,18 +89,6 @@ RollCall votes being considered +-2): change will be approved once 2
 `RollCall+1` (other than the change owner) are posted (and no
 `RollCall-1`).
 
-Delegated tags
---------------
-
-:Gerrit topic: the name of the tag being applied (``stable:follows-policy``,
-               ``vulnerability:managed``)
-
-Some tags are delegated to a specific team, like
-:ref:`tag-stable:follows-policy`
-or :ref:`tag-vulnerability:managed`. Those need to get approved by the
-corresponding team PTL, and can be directly approved by the chair once this
-approval is given.
-
 Delegated metadata
 ------------------
 
@@ -116,7 +104,7 @@ Other project team updates
 :Gerrit topic: ``project-update``
 
 This topic is used for other changes within an existing project team, like
-addition of a new git repository, retirement or self-assertion of a tag.
+addition of a new git repository or retirement.
 
 If there is no objection posted after the addition or retirement of a project
 is proposed (assuming the correct retirement process has been followed), then

reference/index.rst

@@ -28,7 +28,6 @@ Reference documents which need to be revised over time.
    irc
    release-naming
    tags/index
-   Template for new tags <tag-template>
    Requirements for previously-used incubation/integration process <incubation-integration-requirements>
    house-rules
    comparison-of-official-group-structures

reference/projects.yaml

@@ -47,10 +47,8 @@ barbican:
       repos:
         - openstack/barbican
       tags:
-        - starter-kit:kubernetes-in-virt
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     ansible-role-atos-hsm:
       repos:
@@ -132,11 +130,7 @@ cinder:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
-        - assert:supports-rolling-upgrade
-        - assert:supports-accessible-upgrade
-        - assert:supports-api-interoperability
     cinder-specs:
       release-management: none
       repos:
@@ -254,11 +248,8 @@ designate:
       repos:
         - openstack/designate
       tags:
-        - starter-kit:kubernetes-in-virt
         - stable:follows-policy
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - assert:supports-accessible-upgrade
     designate-dashboard:
       repos:
         - openstack/designate-dashboard
@@ -352,9 +343,6 @@ glance:
         - openstack/glance
       tags:
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - starter-kit:compute
-        - starter-kit:kubernetes-in-virt
         - vulnerability:managed
         - stable:follows-policy
     glance-specs:
@@ -398,9 +386,7 @@ heat:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
-        - assert:supports-rolling-upgrade
     heat-agents:
       repos:
         - openstack/heat-agents
@@ -457,7 +443,6 @@ horizon:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     ui-cookiecutter:
       release-management: none
@@ -570,20 +555,13 @@ ironic:
         - openstack/ironic
       tags:
         - stable:follows-policy
-        - assert:supports-upgrade
-        - assert:supports-accessible-upgrade
-        - assert:supports-rolling-upgrade
         - assert:follows-standard-deprecation
-        - assert:supports-standalone
     ironic-inspector:
       repos:
         - openstack/ironic-inspector
       tags:
         - stable:follows-policy
-        - assert:supports-upgrade
-        - assert:supports-accessible-upgrade
         - assert:follows-standard-deprecation
-        - assert:supports-standalone
     ironic-inspector-specs:
       release-management: none
       repos:
@@ -665,11 +643,8 @@ keystone:
       repos:
         - openstack/keystone
       tags:
-        - starter-kit:compute
-        - starter-kit:kubernetes-in-virt
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     keystone-specs:
       release-management: none
@@ -774,8 +749,6 @@ kuryr:
     kuryr-kubernetes:
       repos:
         - openstack/kuryr-kubernetes
-      tags:
-        - starter-kit:kubernetes-in-virt
     kuryr-tempest-plugin:
       repos:
         - openstack/kuryr-tempest-plugin
@@ -828,12 +801,8 @@ manila:
       repos:
         - openstack/manila
       tags:
-        - starter-kit:kubernetes-in-virt
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - assert:supports-accessible-upgrade
         - stable:follows-policy
-        - assert:supports-api-interoperability
     manila-image-elements:
       repos:
         - openstack/manila-image-elements
@@ -1120,13 +1089,8 @@ neutron:
         - openstack/neutron
       tags:
         - stable:follows-policy
-        - starter-kit:compute
-        - starter-kit:kubernetes-in-virt
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - assert:supports-rolling-upgrade
-        - assert:supports-api-interoperability
     neutron-dynamic-routing:
       repos:
         - openstack/neutron-dynamic-routing
@@ -1193,15 +1157,9 @@ nova:
       repos:
         - openstack/nova
       tags:
-        - starter-kit:compute
-        - starter-kit:kubernetes-in-virt
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - assert:supports-rolling-upgrade
-        - assert:supports-accessible-upgrade
         - stable:follows-policy
-        - assert:supports-api-interoperability
     nova-specs:
       release-management: none
       repos:
@@ -1218,9 +1176,6 @@ nova:
     placement:
       repos:
         - openstack/placement
-      tags:
-        - starter-kit:compute
-        - starter-kit:kubernetes-in-virt
     os-traits:
       repos:
         - openstack/os-traits
@@ -1250,10 +1205,7 @@ octavia:
       repos:
         - openstack/octavia
       tags:
-        - starter-kit:kubernetes-in-virt
         - stable:follows-policy
-        - assert:supports-upgrade
-        - assert:supports-accessible-upgrade
     octavia-dashboard:
       repos:
         - openstack/octavia-dashboard
@@ -2737,7 +2689,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-dashboard:
       repos:
@@ -2763,7 +2714,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-plugin-cdh:
       repos:
@@ -2771,7 +2721,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-plugin-mapr:
       repos:
@@ -2779,7 +2728,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-plugin-spark:
       repos:
@@ -2787,7 +2735,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-plugin-storm:
       repos:
@@ -2795,7 +2742,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-plugin-vanilla:
       repos:
@@ -2803,7 +2749,6 @@ sahara:
       tags:
         - vulnerability:managed
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
         - stable:follows-policy
     sahara-tests:
       repos:
@@ -2965,9 +2910,6 @@ swift:
         - vulnerability:managed
         - stable:follows-policy
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
-        - assert:supports-rolling-upgrade
-        - assert:supports-standalone
     swift-bench:
       repos:
         - openstack/swift-bench
@@ -3031,7 +2973,6 @@ Telemetry:
         - openstack/ceilometer
       tags:
         - assert:follows-standard-deprecation
-        - assert:supports-upgrade
     telemetry-specs:
       release-management: none
       repos:
@@ -3337,8 +3278,6 @@ watcher:
     watcher:
       repos:
         - openstack/watcher
-      tags:
-        - assert:supports-upgrade
     watcher-specs:
       release-management: none
       repos:

reference/tag-template.rst

@@ -1,87 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-..
-  This template should be in ReSTructured text. Please do not delete
-  any of the sections in this template.  If you have nothing to say
-  for a whole section, just write: "None". For help with syntax, see
-  http://sphinx-doc.org/rest.html To test out your formatting, see
-  http://www.tele3.cz/jbar/rest/rest.html
-
-.. Modify the next line to replace <proposed-tag-name> with the tag
-   name, then remove this comment.
-
-.. _`tag-<proposed-tag-name>`:
-
-========================================================================
-proposed-tag-name (should match the tags/proposed-tag-name.rst filename)
-========================================================================
-
-..
-  Tag names can contain a prefix that represents the category of tag.
-  Category prefixes should end in a colon (:). Category prefixes as
-  well as tag names should follow a lowercased-hyphen-separated
-  style. Examples: 'release:coordinated' or 'docs:api-reference-complete'
-
-Introduction paragraph -- a short summary of what this tag will mean.
-
-
-Application to current deliverables
-===================================
-
-As part of the application you need to go through the exercise of applying
-the proposed tag to at least some subset of the current deliverables or teams
-(depending on whether the tag applies to teams or deliverables). This
-will serve as an example of how the tag should be applied in the real world.
-You may also submit (as a subsequent change) the corresponding governance
-change to immediately apply the proposed tag to deliverables or teams.
-
-.. tagged-projects:: <tag name>
-
-
-Rationale
-=========
-
-The detailed reason why the OpenStack ecosystem benefits from having this tag
-defined.
-
-
-Requirements
-============
-
-* A list of requirements for granting the tag to an existing project.
-* All the criteria should be objective and predictable.
-* If a tag requires another tag, this should be mentioned here.
-
-
-Tag application process
-=======================
-
-Details of the process to follow to maintain the tag. Are additions/removals
-regularly reviewed, or are they considered only upon request ? Which group
-is involved, and at which frequency ?
-
-The process may include requiring feedback from specific groups, delegation
-of tag maintenance from the TC, minimum delays between application and tag
-grant, timeframes where granting or removing the tag is appropriate, etc.
-
-If the grant process is different from the removal process, this should also
-be mentioned here.
-
-By default, you can use the following process:
-
-Anyone may propose adding or removing this tag to a set of projects by
-proposing a change to the openstack/governance repository. The change is
-reviewed by the Technical Committee and approved using standard resolution
-approval rules, including discussion at at least one Technical Committee
-public IRC meeting.
-
-
-Deprecation
-===========
-
-Some tags may have a deprecation period (where a project retains the tag but
-only until a certain announced date). If the proposed tag has a deprecation
-period, its duration (and any other specific rules) should be listed here.

reference/tags/assert_supports-accessible-upgrade.rst

@@ -1,61 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-assert:supports-accessible-upgrade`:
-
-==================================
-assert:supports-accessible-upgrade
-==================================
-
-This tag is part of the assert category of tags, which are assertions made by
-the project team themselves about the maturity of their deliverables.
-
-The ``assert:supports-accessible-upgrade`` tag asserts that in addition to a
-deliverable supporting basic :ref:`upgrade capabilities
-<tag-assert:supports-upgrade>`, it does so *without disrupting the
-accessibility of controlled resources.*.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: assert:supports-accessible-upgrade
-
-
-Rationale
-=========
-
-Many OpenStack services control and manage compute, networking and data storage
-resources for end users. Operators need to know which services support an
-upgrade process that maintains end user accessibility to controlled resources
-during the upgrade process.
-
-Requirements
-============
-
-* The deliverable is a software component of an OpenStack cloud
-  (openstack, openstack-operations on the map) delivering a long-lived
-  service with an API.
-
-* The deliverable has already successfully asserted the
-  :ref:`tag-assert:supports-upgrade` tag. All the requirements for that tag are
-  requirements for this tag, and assertion that tag is a requirement to assert
-  this tag.
-
-* In addition to the plan required by the :ref:`tag-assert:supports-upgrade`
-  tag, which allows for upgrades to disrupt end user accessibility of
-  controlled resources, this tag requires services to eliminate any abnormal
-  disruption of accessibility to controlled resources during the upgrade
-  process when using at least one documented configuration. For example,
-  upgrades should not take managed resources offline or otherwise make them
-  inaccessible. Conversely, configurations that may result in
-  abnormal disruption, and any limitations of the upgrade process that may
-  affect accessibility, must be explicitly documented as such.
-
-* In addition to the full stack integration testing required by the
-  :ref:`tag-assert:supports-upgrade` tag, the accessibility of controlled
-  resources should be maintained throughout the upgrade process. In order to
-  assert this tag, services should prevent regression by implementing a gate
-  job wherein accessibility of a controlled resource is validated throughout
-  the upgrade process.

reference/tags/assert_supports-api-interoperability.rst

@@ -1,70 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-assert:supports-api-interoperability`:
-
-====================================
-assert:supports-api-interoperability
-====================================
-
-This tag is part of the assert category of tags, which are assertions
-made by the project team themselves about their maturity. One such assertion
-(or self-imposed contract) is about the interoperability of the API. In this
-context interoperability is a combination of an API that's both stable and compatible.
-
-The "assert:supports-api-interoperability" tag asserts that the project will
-follow the API interoperability guidelines and that they will not change (or
-remove) an API in a way that will break existing users of an API.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: assert:supports-api-interoperability
-
-Rationale
-=========
-
-End users of a given service need to have confidence that the API they are
-using and relying on won't break when they upgrade a cloud or start using their
-code on a new OpenStack cloud. This tag asserts that a service adheres to this
-principle and follows the requirements to ensure this.
-
-Requirements
-============
-
-Project teams can apply this tag to services that they produce to assert the
-service will follow the following process for end-user-visibile API stability:
-
-#. The project follows the `API interoperability guidelines`_ when making
-   changes to the REST API
-#. The projects API uses a versioning scheme (like `microversions`_) or a
-   discoverablity mechanism  to ensure that any new features or other changes
-   to the API are both explicit and discoverable.
-#. There are branchless API tests run on every commit to ensure that the API
-   doesn't change between release boundaries.
-
-Tag application process
-=======================
-
-Anyone may propose adding or removing this tag to a set of projects by
-proposing a change to the openstack/governance repository. The change is
-reviewed by the Technical Committee and approved using standard resolution
-approval rules. As this is an assert tag, it is up to the project itself to
-judge if they are currently meeting the requirements (above) and intend to
-continue doing so.
-
-Deprecation
-===========
-
-This tag has no deprecation period, as that would rather violate the point of
-the tag. If a project chooses to assert the tag then they are making a
-commitment to maintain API interoperability henceforth. If the project chooses
-to no longer maintain that commitment they should remove the tag. If a member
-of the community wishes to claim the project is not meeting the commitment a
-proposal should be made removing the tag from the project whereupon the
-Technical Committee will review the situation using standard processes.
-
-.. _API interoperability guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html
-.. _microversions: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html

reference/tags/assert_supports-rolling-upgrade.rst

@@ -1,59 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-assert:supports-rolling-upgrade`:
-
-===============================
-assert:supports-rolling-upgrade
-===============================
-
-This tag is part of the assert category of tags, which are assertions
-made by the project team themselves about the maturity of their deliverables. One
-such assertion (or self-imposed contract) is about the rolling upgrade
-features that the deliverable supports.
-
-The "assert:supports-rolling-upgrade" tag asserts that the deliverable
-will support minimal rolling upgrade capabilities.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: assert:supports-rolling-upgrade
-
-
-Rationale
-=========
-
-OpenStack components represent code that is installed and deployed on
-many distributed systems in order to provide services to
-users. Operators need to know what services support a rolling upgrade
-process to avoid significant downtime.
-
-Requirements
-============
-
-* The deliverable is a software component of an OpenStack cloud
-  (openstack, openstack-operations on the map) delivering a long-lived
-  service with an API.
-* The deliverable has already successfully asserted the supports-upgrade
-  tag. All the requirements for that tag are requirements for this
-  tag, and assertion of that tag is a requirement to assert this tag.
-* The project has a defined plan that allows operators to roll out new
-  code to subsets of services, eliminating the need to restart all
-  services on new code simultaneously. This plan should clearly call
-  out the supported configuration(s) that are expected to work, unless
-  there are no such caveats. This does not require complete
-  elimination of downtime during upgrades, but rather reducing the
-  scope from "all services" to "some services at a time." In other
-  words, "restarting all API services together" is a reasonable restriction.
-* Full stack integration testing with services arranged in a
-  mid-upgrade manner is performed on every proposed commit to validate
-  that mixed-version services work together properly. This testing
-  must be performed on configurations that the project considers to be
-  its reference implementations. The arrangement(s) tested will depend
-  on the project (i.e. should be representative of a
-  meaningful-to-operators rolling upgrade scenario) and available
-  testing resources. At least one representative arrangement must be
-  tested full-stack in the gate.

reference/tags/assert_supports-standalone.rst

@@ -1,41 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-assert:supports-standalone`:
-
-==========================
-assert:supports-standalone
-==========================
-
-This tag is part of the assert category of tags, which are assertions
-made by the project team themselves about the maturity of their deliverables.
-
-The "assert:supports-standalone" tag asserts that the service can be
-operated without requiring other OpenStack services, if the operator
-so chooses.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: assert:supports-standalone
-
-
-Rationale
-=========
-
-While OpenStack services are designed to work well together to manage
-the datacenter as a whole, some services can be operated independently of
-each other for specific use cases and requirements. Operators need to know
-which services these are in order to consider their adoption.
-
-Requirements
-============
-
-* The core functionality of the service is not affected by being operated
-  without other OpenStack services and limitations are clearly documented.
-* The service either supports another form of authentication separate
-  from Keystone, or no authentication in the case of a single tenant
-  environment.
-* The project tests and gates this deployment strategy.

reference/tags/assert_supports-upgrade.rst

@@ -1,64 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-assert:supports-upgrade`:
-
-=======================
-assert:supports-upgrade
-=======================
-
-This tag is part of the assert category of tags, which are assertions
-made by the project team themselves about the maturity of their deliverables. One
-such assertion (or self-imposed contract) is about the cold-upgrade
-features that the deliverable supports.
-
-The "assert:supports-upgrade" tag asserts that the deliverable will
-support minimal cold (offline) upgrade capabilities.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: assert:supports-upgrade
-
-
-Rationale
-=========
-
-OpenStack components represent code that is installed and deployed on
-many distributed systems in order to provide services to
-users. Operators need to know what services support a controlled and
-planned upgrade process from release to release in order to make good
-decisions about what to expose to users. Utilizing an OpenStack
-project in a deployment where smooth upgrades are not provided is a
-danger that operators should be aware of.
-
-Requirements
-============
-
-* The deliverable is a software component of an OpenStack cloud
-  (openstack, openstack-operations on the map) delivering a long-lived
-  service with an API.
-* Configuration from release N-1 is supported in release N. Sane
-  defaults for new configuration variables are provided in such a way
-  that deployed code from N can be expected to run without operator
-  intervention.
-* Database schema updates are stable and ordered such that moving a
-  database (with actual data in it) from release N-1 to N is possible
-  without data loss. This must be actively tested full-stack on every
-  proposed commit in the gate, with resources present and working
-  before and after the upgrade step.
-* A procedure for general upgrades of the deliverable is defined and does
-  not change substantially from cycle to cycle.
-* The project provides an upgrade impact section on the release notes
-  page that highlights anything that must be done by operators for
-  each cycle outside the normal upgrade procedures.
-* The upgrade procedure does not result in any state changes to
-  controlled resources, but may disrupt their accessibility. This
-  allowance is eliminated by the
-  :ref:`tag-assert:supports-accessible-upgrade` tag.
-* Full stack integration testing is performed on every proposed commit
-  to validate that cold upgrades from the previous stable release are
-  not broken. Any upgrade tasks that would be documented as above are
-  codified in the testing to demonstrate correctness.

reference/tags/index.rst

@@ -2,73 +2,16 @@
  Tags
 ======
 
-Tag application processes
+The tags framework is currently being removed. This index page is left
-=========================
+to serve as a source of still-useful information which will be later
+refactored.
 
-Unless a specific tag, or group of tags, states otherwise, the criteria
+Current tags
-required for each tag is objective and anyone may propose adding or removing
+============
-tags to a set of projects by proposing a change to the ``openstack/governance``
-repository. The change is reviewed by the Technical Committee and approved
-using standard resolution approval rules, including discussion during at least
-one Technical Committee public IRC meeting.
-
-The Technical Committee may approve any future updates to tag definitions and
-otherwise defer applications of tags.
-
-TC Managed Tags
-===============
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   starter-kit_compute
-   starter-kit_kubernetes-in-virt
-
-
-Team Description Tags
-=====================
-
-.. toctree::
-   :maxdepth: 1
-
-   status_maintenance-mode
-
-Project Assertion Tags
-======================
-
-Project assertion tags are set by the project team PTL or suitable designee
-based on meeting the documented criteria.
-
-The project asserting these tags should do so when the documented requirements
-are met for the reference implementation(s) or configuration(s) officially
-adopted by that project.
-
-The Technical Committee may exceptionally remove tags if they find that the
-project doesn't actually meet the documented criteria.
 
 .. toctree::
    :maxdepth: 1
 
    assert_follows-standard-deprecation
-   assert_supports-api-interoperability
-   assert_supports-upgrade
-   assert_supports-accessible-upgrade
-   assert_supports-rolling-upgrade
-   assert_supports-standalone
-
-Vulnerability Management Tags
-=============================
-
-.. toctree::
-   :maxdepth: 1
-
    vulnerability_managed
-
-Stable Maintenance Tags
-=======================
-
-.. toctree::
-   :maxdepth: 1
-
    stable_follows-policy

reference/tags/starter-kit_compute.rst

@@ -1,214 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-starter-kit:compute`:
-
-===================
-starter-kit:compute
-===================
-
-A common starting point for a Compute oriented OpenStack cloud that
-can be expanded over time to include more of the OpenStack universe.
-
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: starter-kit:compute
-
-
-Rationale
-=========
-
-The OpenStack Mission Statement: "To produce the ubiquitous Open
-Source Cloud Computing platform that will meet the needs of public and
-private clouds regardless of size, by being simple to implement and
-massively scalable."
-
-When new deployers first approach OpenStack as a project, they are
-presented with a vast and wonderful array of choices of components
-they could choose to begin with. So vast and wonderful that it becomes
-really hard for people to understand where to start; be confident
-that decisions they make will prevent them from deploying something
-usable; and ensure they are able to expand the scope of their
-OpenStack over time.
-
-This paralysis of choice leads to substantial confusion and
-frustration, and drives a lot of would-be-adopters away for other
-stacks where there is a more clear starting point.
-
-Because there has been such a robust discussion around this proposed
-tag, this tag definition attempts to clarify major questions and
-rationale that we've seen up to this point.
-
-Why a *Compute* Starter Kit?
-----------------------------
-
-There are many ways one can use OpenStack, but based on the most
-recent User Survey, 98% of Production and Dev / Test clouds are using
-Nova [1], the highest of all OpenStack components. Even with a margin
-of error, we can assume that a Compute cloud is a key feature that's
-wanted by nearly everyone that enters our community.
-
-Why a Compute *Starter Kit*?
-----------------------------
-
-The intent is to define a small subset of projects that allow the
-deployer to experiment with both stateful and stateless uses of
-OpenStack. The target audience is someone new to cloud computing that
-is kicking the tires on a small number of servers in a basement or
-back room. It's an attempt to frame OpenStack in a way that it will
-come in through the back door of an organization by curious and
-adventurous Ops folks (like Linux did in the early days), not just
-through the front door via a sales channel.
-
-Starter Kit implies this is not the end point, but just a beginning.
-
-Why is this needed?
--------------------
-
-The 'big tent' project structure reform of 2014 has been great for expanding
-the scope and features that are part of OpenStack. However that has scared and
-confused many members of our community who used the integrated release as
-their starting point, and see that now going away. Smaller Operators,
-Trainers, Hobbyists all have been asking the question, "where do I
-start?".
-
-The TC can either frame the question and provide the answer, or we can
-abdicate on this issue and leave it to others. I think we do a
-disservice to our community to punt on this issue.
-
-Isn't this just Defcore?
-------------------------
-
-The starter kit doesn't intend to be Defcore. It's not expected that a
-starter kit compute cloud has enough features to actually be Defcore
-compliant. This is about a base minimal set of features to get people
-familiar with the OpenStack universe. It's the hope that compute
-starter kits could grow up into actual Defcore compatible clouds
-before they move into production.
-
-How would one expand on the Starter Kit?
-----------------------------------------
-
-The vision for the starter kit is it's a starting place, with function
-that nearly all clouds will eventually want to have, and then
-documented ways to expand the cloud into additional functions. Where at all
-possible, expanding the Starter Kit should be a non-disruptive add rather
-than a replacement of one option for another.
-
-For instance, a Compute Starter Kit which starts with a file based
-Glance is completely suitable for a small number of base
-images. However as the needs of such a cloud grow, there becomes a
-point at which this is no longer true, and adding a Swift installation
-to handle image storage is a much better option. The user could then
-migrate their content from file based to Swift. This also exposes them
-to a new set of things they can do with an Object API in their
-OpenStack environment.
-
-The same kind of natural expansion could be done with projects such as
-Heat, Trove, Sahara and others when higher level functionality is
-desired out of their OpenStack cloud.
-
-For some things where there are natural choices, such as Nova Network
-or Neutron, it's important to keep the ability to naturally expand the cloud
-over time in mind. While Nova Network is simpler to set up and run, the
-transition to a Neutron-based cloud is not the same as swapping out a
-Glance storage backend. It is for that reason that the starter-kit
-recommends starting with Neutron configured for Provider Networks
-with Linux Bridge as a simple enough configuration which still has the
-possibility to add more complex SDN backends at a later date.
-
-Doesn't this conflate multiple compute use cases?
--------------------------------------------------
-
-The moment you start a conversation about cloud "use cases" you assume
-a reasonably mature understanding of cloud and all its possible use
-cases (aka: stateful mail servers, stateless build servers, elastic
-webservers to handle holiday load). People that already have "use
-cases" likely do not need a starter kit.
-
-The starter kit concept is for people that are early in their cloud
-journey. These are people that do not yet have use cases, and probably
-won't until they experiment some with a starter kit.
-
-For those people starting their journey into cloud computing,
-it provides an easy way to get used to API driven ephemeral computes.
-This allows them to see how existing workloads
-would fit in OpenStack, as well as the possibilities for building new
-OpenStack / cloud native workloads. Although support for persistent
-volumes is not included, the persistence of ephemeral drives is actually
-already as good as the persistence of local-disk workloads, and it is a
-non-disruptive addition to include persistent volumes in the future
-should the user decide they want them.
-
-Does this mean all users have to start here?
---------------------------------------------
-
-Absolutely not. OpenStack is a wide and vast ecosystem of really
-interesting projects. Anyone who feels they don't need this guidance
-is welcome to ignore it and build the right purpose built cloud for
-them. This is meant as a bridge to those users who don't feel
-confident doing that to bring them into the OpenStack universe.
-
-Requirements
-============
-
-* All projects must actively maintain stable branches
-
-  Rationale: these users will typically deploy stable releases only,
-  and upgrade on stable point releases before jumping to the next
-  stable release.
-
-* All projects must only use relational database and queue system
-
-  Rationale: providing HA stories for a relational database and amqp
-  is substantial operational burden. Additional storage / messaging
-  technologies provide too high an operational burden to meet for
-  initial setup.
-
-* All projects must use oslo.config, oslo.log
-
-  Rationale: both of these are operator in / out surfaces. All
-  projects in here should have the same mechanisms for input / output
-  from an operational standpoint.
-
-* All projects must support upgrade without config file change
-
-  Rationale: the expected upgrade model is code upgrade on existing
-  config files, cleaning up deprecation issues before upgrading to the next.
-
-* All projects must be a required to put a persistent VM on the network.
-
-  Rationale: we'd like to create a small enough starting point that
-  getting everything up and running is a manageable project. We'd like
-  to support persistent VMs because it's something most operators are
-  going to immediately have a use for, and can thus try it out for
-  real in their environment.
-
-* The projects in this tag should make it easy to add new OpenStack
-  projects into such a deployment over time.
-
-  Rationale: we'd like this to be a solid bit of 'seed corn' from
-  which a larger and richer OpenStack deployment can be built out
-  over time. Starting small with the ability to grow helps OpenStack adoption.
-
-
-Tag application process
-=======================
-
-There is no need to apply for addition or removal.
-
-Deprecation
-===========
-
-No deprecation assumed, though there is the assumption that this
-concept will be revisited at every major release boundary for
-suitability.
-
-
-References
-==========
-[1] - http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

reference/tags/starter-kit_kubernetes-in-virt.rst

@@ -1,161 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-.. _`tag-starter-kit:kubernetes-in-virt`:
-
-==============================
-starter-kit:kubernetes-in-virt
-==============================
-
-A common starting point for an OpenStack cloud that can be used to deploy
-Kubernetes clusters on virtual machines in multiple tenants, and provides all
-of the services that Kubernetes expects from a cloud.
-
-Application to current deliverables
-===================================
-
-.. tagged-projects:: starter-kit:kubernetes-in-virt
-
-Rationale
-=========
-
-Many application developers now target the Kubernetes API, rather than any
-specific cloud API, as the 'operating system' for cloud-native applications.
-Kubernetes is designed to run within a cloud, and to expect the cloud to
-provide multitenant isolation between different Kubernetes clusters. OpenStack
-can supply this, but it is not always clear to users without a lot of research
-which capabilities are expected by Kubernetes and hence which OpenStack
-services are required to support them. The starter kit provides guidance to
-potential users on how to get started building a cloud that meets these
-requirements.
-
-Included Features
------------------
-
-Compute
-~~~~~~~
-
-Kubernetes runs on servers, and this starter kit focuses (as most clouds do) on
-virtual machines, so the projects in the :doc:`Compute Starter Kit
-<starter-kit_compute>` for providing minimal multitenant management of
-virtual machines are required.
-
-File Storage
-~~~~~~~~~~~~
-
-Almost all applications running on Kubernetes will require persistent storage,
-and of those requiring persistent *local* storage, most will prefer RWX
-(Read/Write Many) semantics to prevent downtime when pods move around. Manila
-provides RWX-capable persistent file storage for containers running in
-Kubernetes via the `Manila CSI plugin`_.
-
-Networking
-~~~~~~~~~~
-
-Kubernetes clusters need to be connected to tenant networks, so the Neutron
-project (which is also part of the :doc:`Compute Starter Kit
-<starter-kit_compute>`) is included.
-
-`Kuryr-kubernetes`_ is a collection of tools that run in tenant clusters to
-enable direct use of Neutron networks from containers running in Kubernetes,
-avoiding a second network overlay layer.
-
-Load Balancing
-~~~~~~~~~~~~~~
-
-Most externally-facing HTTP services running in Kubernetes will typically use
-an Ingress to provide load balancing and :abbr:`TLS (Transport Layer Security)`
-termination (amongst other things). Octavia provides a highly-available, truly
-load-balanced solution for this --- which is difficult or impossible to get
-from anything but an underlying cloud --- via the `Octavia Ingress Controller`_
-
-Both kuryr-kubernetes and the `OpenStack Cloud Controller Load Balancer
-module`_ also use Octavia to provide load balancing for Services of type
-``LoadBalancer``. Unlike Ingresses, which share a Layer 7 load balancer, each
-Service of this type in Kubernetes gets its own load balancer. For OpenStack
-clouds using the `OVN <https://www.ovn.org/>`_ backend for Neutron, the `OVN
-driver for Octavia
-<https://docs.openstack.org/ovn-octavia-provider/latest/admin/driver.html>`_
-offers a lightweight Layer 4 network load balancing implementation for Services
-that don't require higher-layer features.
-
-DNS
-~~~
-
-Every Kubernetes cluster requires a DNS record for the control plane, and a
-wildcard DNS record for any services running in the cluster. Designate allows
-tenants to configure these autonomously, so that setting up clusters within a
-tenant project doesn't require manual intervention from an administrator, and
-its integration with Neutron means it can act as a trusted source of Reverse
-DNS records.
-
-DNS records for services running within the cluster can also be exported to
-Designate via its integration with the Kubernetes `ExternalDNS
-<https://github.com/kubernetes-sigs/external-dns#readme>`_ project.
-
-Key Management
-~~~~~~~~~~~~~~
-
-By default, Kubernetes Secrets aren't. Even if you `enable encryption
-<https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/>`_, the
-encryption keys are merely stored in etcd alongside the data they encrypt,
-meaning that if the database is leaked it might as well not be encrypted at
-all. It's turtles all the way down until you get to a `key management service
-<https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/>`_
-(preferably backed by an HSM) provided by the cloud, such as Barbican. This is
-accessed through the `Barbican KMS plugin`_.
-
-Notable Omissions
------------------
-
-Bare Metal Compute
-~~~~~~~~~~~~~~~~~~
-
-The addition of Ironic would allow Kubernetes to be deployed on bare metal
-also. However, this is not included in the starter kit both because it is not
-strictly necessary and because the overall shape of a bare metal--specific
-cloud for hosting Kubernetes might look `different
-<https://governance.openstack.org/ideas/ideas/teapot/index.html>`_.
-
-Block Storage
-~~~~~~~~~~~~~
-
-Although Cinder block storage can be, and often is, used from Kubernetes via
-the `Cinder CSI plugin`_, it offers only RWO (Read/Write One) semantics, and is
-thus more limited than Manila.
-
-Users with other use cases for Cinder (such as requiring persistent volumes in
-OpenStack) may choose to deploy it alongside or sometimes instead of Manila,
-but it is not the first choice for a minimal starter kit.
-
-Object Storage
-~~~~~~~~~~~~~~
-
-Object storage such as that provided by Swift is a very common requirement for
-cloud-native applications, whether they run in Kubernetes or directly in a
-cloud such as OpenStack. However, this storage tends to be accessed purely at
-the application level, and not via Kubernetes APIs. (However, there is `a
-proposal <https://github.com/kubernetes/enhancements/pull/1383>`_ to change
-this.) Since the requirement is application-dependent, object storage is not
-included in the starter kit.
-
-Tag application process
-=======================
-
-There is no need to apply for addition or removal.
-
-Deprecation
-===========
-
-No deprecation assumed, though there is the assumption that this concept may be
-revisited at any major release boundary for suitability.
-
-
-.. _Kuryr-kubernetes: https://docs.openstack.org/kuryr-kubernetes/
-.. _Manila CSI plugin: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-manila-csi-plugin.md#readme
-.. _Octavia Ingress Controller: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-octavia-ingress-controller.md#readme
-.. _OpenStack Cloud Controller Load Balancer module: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-openstack-cloud-controller-manager.md#load-balancer
-.. _Barbican KMS plugin: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-barbican-kms-plugin.md#readme
-.. _Cinder CSI plugin: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md#readme

reference/tags/status_maintenance-mode.rst

@@ -1,101 +0,0 @@
-..
-  This work is licensed under a Creative Commons Attribution 3.0
-  Unported License.
-  http://creativecommons.org/licenses/by/3.0/legalcode
-
-..
-  This template should be in ReSTructured text. Please do not delete
-  any of the sections in this template.  If you have nothing to say
-  for a whole section, just write: "None". For help with syntax, see
-  http://sphinx-doc.org/rest.html To test out your formatting, see
-  http://www.tele3.cz/jbar/rest/rest.html
-
-.. _`tag-status:maintenance-mode`:
-
-=======================
-status:maintenance-mode
-=======================
-
-The status:maintenance-mode tag is a project team level tag.
-
-There are situations the project team or the TC wish to indicate that
-a project team is in a period of low activity (which we call
-'maintenance-mode'). This is accomplished by applying the
-status:maintenance-mode tag to the project team.
-
-Application to current teams
-============================
-
-.. tagged-projects:: status:maintenance-mode
-
-
-Rationale
-=========
-
-From time to time, and for any number of reasons, a project team
-enters a period where there is reduced activity and contribution.
-
-When a project team, or the Technical Committee determine that a
-project team is in such a transient state, the 'maintenance-mode' tag
-can be applied to it. The application of the tag signals to all that
-the project team is in this mode, and they can set their expectations
-on activity accordingly.
-
-The following section (Requirements) describes the requirements for a
-the tag to be applied.
-
-Requirements
-============
-
-The tag can be applied by the Technical Committee or the project team,
-the project team has entered a transient period of low activity.
-
-It is important to understand that this is intended to be for a
-transient period of low activity, one that can be exited if there are
-additional active contributors who are able to contribute actively to
-the project team.
-
-* the project team has an appointed, and responsive release liaison
-* the project team has an appointed, and responsive liaison to the
-  security team
-* the project team will meet the release goals, and take the necessary
-  actions required to cause a release to be available as part of the
-  regular OpenStack release schedule
-* the project team will fix and release fixes to security issues
-  raised by the VMT
-* the project team will keep their project in line with the global
-  requirements list
-
-When a project team is in maintenance-mode, the following are
-explicitly not guaranteed.
-
-* the project team does not guarantee the review and merging of
-  non-critical bug fixes
-* the project team does not guarantee the implementation and delivery
-  of new features and functionality
-* the project team makes no commitments to respond to queries on the
-  project's IRC channel or on the mailing list
-* the project team makes no commitments to hold its regularly
-  scheduled meetings.
-
-Tag application process
-=======================
-
-This tag is applied either by the Technical Committee or the project
-team (voluntarily).
-
-The application of the tag requires a change to be submitted to the
-governance repository. The change should include a justification for
-why the tag should be applied or removed.
-
-The change is reviewed by the Technical Committee and discussed with
-the project team. It should be approved using standard resolution
-approval rules, including discussion at at least one Technical
-Committee public IRC meeting.
-
-Deprecation
-===========
-
-The Technical Committee may from time to time review project teams
-that are in maintenance-mode to consider other actions (such as making
-the project unofficial) as they feel is appropriate.

resolutions/20141202-project-structure-reform-spec.rst

@@ -1,3 +1,5 @@
+.. _20141202_project_structure_reform_spec:
+
 =============================================================
  2014-12-02 OpenStack project structure reform specification
 =============================================================

resolutions/20170620-volunteer-support.rst

@@ -79,7 +79,7 @@ Deprecation
 In extreme cases, if a feature or driver can no longer be maintained, the
 implementation must be removed.
 Projects that are stable and widely deployed are expected to sign
-up for the :ref:`tag-assert:follows-standard-deprecation`. This gives us a
+up for the follows-standard-deprecation tag. This gives us a
 controlled way to warn users about such features or drivers that are being
 replaced or at risk of being removed.
 

resolutions/20211224-tags-framework-removal.rst

@@ -0,0 +1,21 @@
+.. _20211224_tags_framework_removal:
+
+========================================
+2021-12-24 Removal of the tags framework
+========================================
+
+With the advent of :doc:`20141202-project-structure-reform-spec`, the TC
+started using a tags framework to describe various expectations of the projects
+making up OpenStack. The primary target audience was operators. However,
+it turned out that the tags framework data was neither complete
+(i.e., certain assumptions were not asserted with the tags)
+nor precise
+(i.e., the assumptions tags made might not have been exercised in practice)
+and, at least recently, there was no positive feedback on the usefulness of
+the tags framework. [1]_
+Hence, the TC has concluded that the tags frameworks should be removed.
+[2]_ [3]_
+
+.. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024804.html
+.. [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html
+.. [3] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025571.html

tools/base.py

@@ -1,33 +0,0 @@
-# Licensed under the Apache License, Version 2.0 (the "License"); you may
-# not use this file except in compliance with the License. You may obtain
-# a copy of the License at
-#
-#      http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-# License for the specific language governing permissions and limitations
-# under the License.
-
-import abc
-import six
-
-
-@six.add_metaclass(abc.ABCMeta)
-class ValidatorBase(object):
-
-    @staticmethod
-    @abc.abstractmethod
-    def get_tag_name():
-        """Return tag name."""
-        return
-
-    @staticmethod
-    @abc.abstractmethod
-    def validate(name):
-        """Return True if name should have the tag.
-
-        Where name can be a team or repo
-        """
-        return

tools/check_review_status.py

@@ -337,7 +337,6 @@ def get_one_status(change, delegates, tc_members):
             can_approve = 'CAN APPROVE'
 
     elif topic in delegates.keys():
-        # https://governance.openstack.org/tc/reference/house-rules.html#delegated-tags
         # https://governance.openstack.org/tc/reference/house-rules.html#delegated-metadata
         approver_name = delegates[topic]
         can_approve = 'delegated to {}'.format(approver_name)
@@ -449,8 +448,6 @@ def main():
     release_team = gov.get_team('Release Management')
 
     delegates = {
-        'stable:follows-policy': 'Tony Breeds',
-        'vulnerability:managed': 'VMT',
         'release-management': release_team.ptl['name'],
     }
     for tag, name in sorted(delegates.items()):

tox.ini

@@ -64,9 +64,6 @@ commands =
   find reference/projects -name '*.rst' -a '!' -name index.rst -delete
   sphinx-build -W -b html doc/source doc/build/html
 
-[testenv:validate]
-commands = python3 tools/validate_tags.py
-
 [testenv:check-review-status]
 deps =
   requests