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
This commit is contained in:
parent
f272a40df0
commit
b7f45e2266
|
@ -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
|
||||
the project unofficial) as they feel is appropriate.
|
|
@ -1,3 +1,5 @@
|
|||
.. _20141202_project_structure_reform_spec:
|
||||
|
||||
=============================================================
|
||||
2014-12-02 OpenStack project structure reform specification
|
||||
=============================================================
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
|
@ -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
|
|
@ -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()):
|
||||
|
|
3
tox.ini
3
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
|
||||
|
|
Loading…
Reference in New Issue