The doc team repositories have removed all incubated code already in
Newton cycle, a remaining artifact was removed recently. Document this.
Change-Id: I478ac4218984e1595b8bc335e1c99f37008faa3d
This adds the new ironic-tempest-plugin and
ironic-inspector-tempest-plugin repos to ironic governance, as the
beginning of the effort to split our tempest plugins to a separate repo.
Depends-On: I0fdb88d588608538720e4f3e1381930df8dd9a6f
Change-Id: I3e426c2f19eb00965eb7eb48b32f9b5e6c797307
Many folks in the broader open source ecosystem have a strong
desire for Kolla to make OpenStack containers available as a
standalone repository.
Agred upon by vote in this upstream mailing list thread:
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103721.html
Depends-On: I09b365d456735b1e1b7696ed323a21b27f1c642a
Change-Id: If1353efd76611128bc7e6dd5b8c52c5a23d4322a
Release models for deliverables may change over time, so we are now
tracking them in the releases repository, where we have a separate file
for each release cycle.
The deliverable "type" tags were only being used to control how the
releases.openstack.org site organizes the data about releases on each
series page, so we are also now tracking the type in the releases
repository.
Since the data associated with these tags is tracked elsewhere, and not
used for governance directly, we can remove the tags.
Change-Id: Iac89ba587ca770004264aaebf1bc856b755e2258
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
TC managed tags don't follow the naming "standard" we've been following
for other tags. There are 2 tags and neither of them use a `tc` prefix
or groupping.
This patch renames the tc-approved-release to tc:approved-release
Change-Id: I2674acefd9018c4f043ce27c9ada201290e64e3f
We have a number of projects whose unit tests don't entirely mock
out database or filesystem interactions, or need specific system
packages preinstalled. Be clear that the CTI doesn't forbid these
sorts of nominal deviations.
Change-Id: Id2ec29f592896ca42a4e720af70d42a6f1eb2aa1
The Mitaka and later releases are tested against a Python 3.5
interpreter instead of 3.4, so update the CTI accordingly.
Change-Id: I07aad53d78acf4c99d0eace49ab71445972f1c87
Adds a plugin for sphinx for generating badges for teams and
deliverables to use in READMEs, docs sites, etc. A badge corresponds
to a tag.
This plugin generates an `svg` image containing team tags and the
deliverable tags for each repo listed. Each tag corresponds to an SVG
image. All the tags are bundled in the same SVG image whose filename
corresponds to the repo name.
Each badge points to the tag link in the governance website.
This not handled yet:
- This doesn't handle "unofficial" projects, which would be nice to
have. If a project tries to access `project-team.svg` tag, instead of
returning 404, we could return a `project:unofficial` badge.
- Specialized colors for some tags. We might want to use different colors
for some groups. Team tags could be orange, etc.
- Group/Order tags generation by tag groups
Here's a dummy repo created as an example of how this work would be
consumed (or look like):
- https://github.com/flaper87/badges-tester
Change-Id: Ic70c17b60c0107e40b78bf21dc3a68c558eee06f
The asserts:supports-zero-downtime-upgrade tag allows for a performance
penalty during the upgrade process, such as delayed responses for
service APIs. This tag raises the bar further by eliminating that
allowance.
As a result of this tag, services are expected to be able to support
upgrading:
* in a rolling fashion (running multiple versions of a service
concurrently),
* without incurring any API downtime (API responses must return without
failure),
* and without incurring any performance penalty (API responses must return
without a perceivable delay from normal operations).
With this patch, the upgrade-related tags would then include:
1. asserts:supports-upgrade
2. asserts:supports-rolling-upgrade
3. asserts:supports-zero-downtime-upgrade
4. asserts:supports-zero-impact-upgrade
Change-Id: If73d936977d8fcab02d1f7be42e00b304391f4c6
In transitioning projects towards a rolling upgrades strategy, it's
become clear that there are additional levels of granularity, reflecting
the additional difficulty of implementing and maintaining acceptable
solutions.
The existing asserts:supports-rolling-upgrade tag allows for minimal
downtime of the control plane during the upgrade process. This tag
raises the bar further by eliminating that allowance.
As a concession, this tag still allows for performance degradation
during the upgrade process, which we could again eliminate in a more
restrictive tag as projects begin to assert this one.
With this patch, the upgrade-related tags would then include:
1. asserts:supports-upgrade
2. asserts:supports-rolling-upgrade
3. asserts:supports-zero-downtime-upgrade
Change-Id: I8b191f7d56702aa21273c61417af4bdf1de2abb0
Oslo-incubator code were used by old cli,
which were deprecated since Liberty release. Since
Ocata release these commands are removed, and all incubated
code was removed.
Change-Id: Ia7d2bc2d7e874ef9295319be98040a7b129dda5f
