diff --git a/doc/source/_exts/badges.py b/doc/source/_exts/badges.py index 952fcaaff..5fb0d37c8 100644 --- a/doc/source/_exts/badges.py +++ b/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): - 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): +def _organize_badges(base_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(), - _get_tag_badges(tags)) + badges = _organize_badges(_get_base_badges()) svg = '\n'.join(_to_svg(chain(*badges))) root_width = max([bdg_row[-1]['width'] + bdg_row[-1]['svg_x'] for bdg_row in badges]) diff --git a/doc/source/_exts/teams.py b/doc/source/_exts/teams.py index 2eaf0be1b..b0c910960 100644 --- a/doc/source/_exts/teams.py +++ b/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 '' diff --git a/goals/completed/stein/upgrade-checkers.rst b/goals/completed/stein/upgrade-checkers.rst index 076a1482f..00e1ee222 100644 --- a/goals/completed/stein/upgrade-checkers.rst +++ b/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 diff --git a/openstack_governance/governance.py b/openstack_governance/governance.py index fa3519fcb..9057cd881 100644 --- a/openstack_governance/governance.py +++ b/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, - tags=[]): + def get_repositories(self, team_name=None, deliverable_name=None): """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 diff --git a/openstack_governance/projects_schema.yaml b/openstack_governance/projects_schema.yaml index 510f98dc7..43d8ad9f7 100644 --- a/openstack_governance/projects_schema.yaml +++ b/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: diff --git a/openstack_governance/tests/test_governance.py b/openstack_governance/tests/test_governance.py index 01cee5d1e..ca1b85759 100644 --- a/openstack_governance/tests/test_governance.py +++ b/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): diff --git a/reference/house-rules.rst b/reference/house-rules.rst index eff113c5d..2b90e9e23 100644 --- a/reference/house-rules.rst +++ b/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 diff --git a/reference/index.rst b/reference/index.rst index facfee21b..63890cad3 100644 --- a/reference/index.rst +++ b/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 Requirements for previously-used incubation/integration process house-rules comparison-of-official-group-structures diff --git a/reference/projects.yaml b/reference/projects.yaml index f7d1a79ee..fd1ae6a8b 100644 --- a/reference/projects.yaml +++ b/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 @@ -1122,13 +1091,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 @@ -1197,15 +1161,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: @@ -1222,9 +1180,6 @@ nova: placement: repos: - openstack/placement - tags: - - starter-kit:compute - - starter-kit:kubernetes-in-virt os-traits: repos: - openstack/os-traits @@ -1254,10 +1209,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 @@ -2741,7 +2693,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-dashboard: repos: @@ -2767,7 +2718,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-plugin-cdh: repos: @@ -2775,7 +2725,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-plugin-mapr: repos: @@ -2783,7 +2732,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-plugin-spark: repos: @@ -2791,7 +2739,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-plugin-storm: repos: @@ -2799,7 +2746,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-plugin-vanilla: repos: @@ -2807,7 +2753,6 @@ sahara: tags: - vulnerability:managed - assert:follows-standard-deprecation - - assert:supports-upgrade - stable:follows-policy sahara-tests: repos: @@ -2969,9 +2914,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 @@ -3035,7 +2977,6 @@ Telemetry: - openstack/ceilometer tags: - assert:follows-standard-deprecation - - assert:supports-upgrade telemetry-specs: release-management: none repos: @@ -3341,8 +3282,6 @@ watcher: watcher: repos: - openstack/watcher - tags: - - assert:supports-upgrade watcher-specs: release-management: none repos: diff --git a/reference/tag-template.rst b/reference/tag-template.rst deleted file mode 100644 index 9ed5b3a32..000000000 --- a/reference/tag-template.rst +++ /dev/null @@ -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 with the tag - name, then remove this comment. - -.. _`tag-`: - -======================================================================== -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:: - - -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. diff --git a/reference/tags/assert_supports-accessible-upgrade.rst b/reference/tags/assert_supports-accessible-upgrade.rst deleted file mode 100644 index 82747aabe..000000000 --- a/reference/tags/assert_supports-accessible-upgrade.rst +++ /dev/null @@ -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 -`, 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. diff --git a/reference/tags/assert_supports-api-interoperability.rst b/reference/tags/assert_supports-api-interoperability.rst deleted file mode 100644 index b8f999dd7..000000000 --- a/reference/tags/assert_supports-api-interoperability.rst +++ /dev/null @@ -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 diff --git a/reference/tags/assert_supports-rolling-upgrade.rst b/reference/tags/assert_supports-rolling-upgrade.rst deleted file mode 100644 index 3b9ecacac..000000000 --- a/reference/tags/assert_supports-rolling-upgrade.rst +++ /dev/null @@ -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. diff --git a/reference/tags/assert_supports-standalone.rst b/reference/tags/assert_supports-standalone.rst deleted file mode 100644 index d7d2ef6de..000000000 --- a/reference/tags/assert_supports-standalone.rst +++ /dev/null @@ -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. diff --git a/reference/tags/assert_supports-upgrade.rst b/reference/tags/assert_supports-upgrade.rst deleted file mode 100644 index 0f0c2ee1d..000000000 --- a/reference/tags/assert_supports-upgrade.rst +++ /dev/null @@ -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. diff --git a/reference/tags/index.rst b/reference/tags/index.rst index d15c2a888..810454fac 100644 --- a/reference/tags/index.rst +++ b/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 -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. +Current tags +============ .. 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 diff --git a/reference/tags/starter-kit_compute.rst b/reference/tags/starter-kit_compute.rst deleted file mode 100644 index e9b3c9058..000000000 --- a/reference/tags/starter-kit_compute.rst +++ /dev/null @@ -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 diff --git a/reference/tags/starter-kit_kubernetes-in-virt.rst b/reference/tags/starter-kit_kubernetes-in-virt.rst deleted file mode 100644 index 3ede3e8de..000000000 --- a/reference/tags/starter-kit_kubernetes-in-virt.rst +++ /dev/null @@ -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 -` 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 -`) 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 `_ backend for Neutron, the `OVN -driver for Octavia -`_ -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 -`_ project. - -Key Management -~~~~~~~~~~~~~~ - -By default, Kubernetes Secrets aren't. Even if you `enable encryption -`_, 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 -`_ -(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 -`_. - -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 `_ 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 diff --git a/reference/tags/status_maintenance-mode.rst b/reference/tags/status_maintenance-mode.rst deleted file mode 100644 index de0df11cf..000000000 --- a/reference/tags/status_maintenance-mode.rst +++ /dev/null @@ -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. diff --git a/resolutions/20141202-project-structure-reform-spec.rst b/resolutions/20141202-project-structure-reform-spec.rst index b0e5cfce8..4f877a6b4 100644 --- a/resolutions/20141202-project-structure-reform-spec.rst +++ b/resolutions/20141202-project-structure-reform-spec.rst @@ -1,3 +1,5 @@ +.. _20141202_project_structure_reform_spec: + ============================================================= 2014-12-02 OpenStack project structure reform specification ============================================================= diff --git a/resolutions/20170620-volunteer-support.rst b/resolutions/20170620-volunteer-support.rst index 32dcce222..4186b0a77 100644 --- a/resolutions/20170620-volunteer-support.rst +++ b/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. diff --git a/resolutions/20211224-tags-framework-removal.rst b/resolutions/20211224-tags-framework-removal.rst new file mode 100644 index 000000000..120d1d42e --- /dev/null +++ b/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 diff --git a/tools/base.py b/tools/base.py deleted file mode 100644 index 9cf13e881..000000000 --- a/tools/base.py +++ /dev/null @@ -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 diff --git a/tools/check_review_status.py b/tools/check_review_status.py index 7e0020b98..067b849c9 100755 --- a/tools/check_review_status.py +++ b/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()): diff --git a/tox.ini b/tox.ini index 7ec0d6f2c..71a0f8494 100644 --- a/tox.ini +++ b/tox.ini @@ -58,9 +58,6 @@ deps = -c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/up -r{toxinidir}/doc/requirements.txt commands = sphinx-build -W -b html doc/source doc/build/html -[testenv:validate] -commands = python3 tools/validate_tags.py - [testenv:check-review-status] deps = requests