Remove the tags framework (part 1)

This change enacts the first steps of the TC's decision to remove
the tags framework. [1]

This change does not remove all the parts to avoid breaking
the releases tooling as well as to preserve useful information
as discussed under this change and during one of the TC meetings.
[2]

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html
[2] https://meetings.opendev.org/meetings/tc/2022/tc.2022-01-20-15.00.log.html

Change-Id: Iab4a136905a9c7a61530ff7576a216d229f717a0
changes/00/822900/5
Radosław Piliszek 9 months ago
parent f272a40df0
commit b7f45e2266
  1. 26
      doc/source/_exts/badges.py
  2. 8
      doc/source/_exts/teams.py
  3. 2
      goals/completed/stein/upgrade-checkers.rst
  4. 31
      openstack_governance/governance.py
  5. 4
      openstack_governance/projects_schema.yaml
  6. 22
      openstack_governance/tests/test_governance.py
  7. 14
      reference/house-rules.rst
  8. 1
      reference/index.rst
  9. 61
      reference/projects.yaml
  10. 87
      reference/tag-template.rst
  11. 61
      reference/tags/assert_supports-accessible-upgrade.rst
  12. 70
      reference/tags/assert_supports-api-interoperability.rst
  13. 59
      reference/tags/assert_supports-rolling-upgrade.rst
  14. 41
      reference/tags/assert_supports-standalone.rst
  15. 64
      reference/tags/assert_supports-upgrade.rst
  16. 67
      reference/tags/index.rst
  17. 214
      reference/tags/starter-kit_compute.rst
  18. 161
      reference/tags/starter-kit_kubernetes-in-virt.rst
  19. 101
      reference/tags/status_maintenance-mode.rst
  20. 2
      resolutions/20141202-project-structure-reform-spec.rst
  21. 2
      resolutions/20170620-volunteer-support.rst
  22. 21
      resolutions/20211224-tags-framework-removal.rst
  23. 33
      tools/base.py
  24. 3
      tools/check_review_status.py
  25. 3
      tox.ini

@ -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])

@ -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 ''

@ -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

@ -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

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

@ -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):

@ -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

@ -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

@ -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:

@ -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.

@ -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.

@ -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

@ -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.

@ -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.

@ -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.

@ -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

@ -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

@ -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

@ -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