Merge "Remove the tags framework (part 1)"
This commit is contained in:
commit
0f758605cc
|
@ -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
|
||||
|
@ -1120,13 +1089,8 @@ neutron:
|
|||
- openstack/neutron
|
||||
tags:
|
||||
- stable:follows-policy
|
||||
- starter-kit:compute
|
||||
- starter-kit:kubernetes-in-virt
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- assert:supports-rolling-upgrade
|
||||
- assert:supports-api-interoperability
|
||||
neutron-dynamic-routing:
|
||||
repos:
|
||||
- openstack/neutron-dynamic-routing
|
||||
|
@ -1193,15 +1157,9 @@ nova:
|
|||
repos:
|
||||
- openstack/nova
|
||||
tags:
|
||||
- starter-kit:compute
|
||||
- starter-kit:kubernetes-in-virt
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- assert:supports-rolling-upgrade
|
||||
- assert:supports-accessible-upgrade
|
||||
- stable:follows-policy
|
||||
- assert:supports-api-interoperability
|
||||
nova-specs:
|
||||
release-management: none
|
||||
repos:
|
||||
|
@ -1218,9 +1176,6 @@ nova:
|
|||
placement:
|
||||
repos:
|
||||
- openstack/placement
|
||||
tags:
|
||||
- starter-kit:compute
|
||||
- starter-kit:kubernetes-in-virt
|
||||
os-traits:
|
||||
repos:
|
||||
- openstack/os-traits
|
||||
|
@ -1250,10 +1205,7 @@ octavia:
|
|||
repos:
|
||||
- openstack/octavia
|
||||
tags:
|
||||
- starter-kit:kubernetes-in-virt
|
||||
- stable:follows-policy
|
||||
- assert:supports-upgrade
|
||||
- assert:supports-accessible-upgrade
|
||||
octavia-dashboard:
|
||||
repos:
|
||||
- openstack/octavia-dashboard
|
||||
|
@ -2737,7 +2689,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-dashboard:
|
||||
repos:
|
||||
|
@ -2763,7 +2714,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-plugin-cdh:
|
||||
repos:
|
||||
|
@ -2771,7 +2721,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-plugin-mapr:
|
||||
repos:
|
||||
|
@ -2779,7 +2728,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-plugin-spark:
|
||||
repos:
|
||||
|
@ -2787,7 +2735,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-plugin-storm:
|
||||
repos:
|
||||
|
@ -2795,7 +2742,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-plugin-vanilla:
|
||||
repos:
|
||||
|
@ -2803,7 +2749,6 @@ sahara:
|
|||
tags:
|
||||
- vulnerability:managed
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- stable:follows-policy
|
||||
sahara-tests:
|
||||
repos:
|
||||
|
@ -2965,9 +2910,6 @@ swift:
|
|||
- vulnerability:managed
|
||||
- stable:follows-policy
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
- assert:supports-rolling-upgrade
|
||||
- assert:supports-standalone
|
||||
swift-bench:
|
||||
repos:
|
||||
- openstack/swift-bench
|
||||
|
@ -3031,7 +2973,6 @@ Telemetry:
|
|||
- openstack/ceilometer
|
||||
tags:
|
||||
- assert:follows-standard-deprecation
|
||||
- assert:supports-upgrade
|
||||
telemetry-specs:
|
||||
release-management: none
|
||||
repos:
|
||||
|
@ -3337,8 +3278,6 @@ watcher:
|
|||
watcher:
|
||||
repos:
|
||||
- openstack/watcher
|
||||
tags:
|
||||
- assert:supports-upgrade
|
||||
watcher-specs:
|
||||
release-management: none
|
||||
repos:
|
||||
|
|
|
@ -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()):
|
||||
|
|
Loading…
Reference in New Issue