OpenStack Infrastructure Blueprint Repository
Go to file
Jeremy Stanley c872f8f6a4 Declare victory on StoryBoard
The original plan to migrate all OpenStack projects may have been
overly-ambitious, but more importantly it's a policy decision
outside the Infrastructure team's immediate sphere of control. Most
identified gaps in the intervening years have been addressed, with
some final ones (like attachments) under review nearing completion
or well into a planning stage (like self-service team management).
There will always be new features some teams want, and indefinitely
delaying completion of this spec for such a treadmill is
unnecessary.

Update the spec to only cover the original well-established first
phase, and remove the hand-wavy stubs for a second phase where
"everybody agrees to migrate." Also remove the dependency on central
identity management as there is no clear path forward on it
presently. Many teams are already relying on StoryBoard today, and
the handful of developers and maintainers for it hold fairly regular
meetings and can be reached readily with questions, concerns or
suggestions. Further improvement to StoryBoard remains a priority
for them, but it doesn't need to be a priority spec for the
Infrastructure team for that to be the case.

Change-Id: I5092211bfe59646f6db0adae6075b41cb312c6ad
2019-12-03 23:52:01 +00:00
doc/source Declare victory on StoryBoard 2019-12-03 23:52:01 +00:00
specs Declare victory on StoryBoard 2019-12-03 23:52:01 +00:00
.coveragerc Change ignore-errors to ignore_errors 2015-09-21 14:23:23 +00:00
.gitignore Move from oslosphinx to openstackdocstheme 2019-05-15 08:14:34 -05:00
.gitreview OpenDev Migration Patch 2019-04-19 19:26:02 +00:00
.mailmap Initial commit 2014-06-10 16:25:32 -07:00
.testr.conf Initial commit 2014-06-10 16:25:32 -07:00
CONTRIBUTING.rst Workflow documentation is now in infra-manual 2014-12-05 11:56:28 -08:00
LICENSE Initial commit 2014-06-10 16:25:32 -07:00
MANIFEST.in Initial commit 2014-06-10 16:25:32 -07:00
README.rst Update site URL 2019-05-30 21:00:18 +02:00
requirements.txt Move from oslosphinx to openstackdocstheme 2019-05-15 08:14:34 -05:00
setup.cfg Update requirements for Sphinx 1.5 2017-03-02 19:11:26 +01:00
setup.py Update requirements for Sphinx 1.5 2017-03-02 19:11:26 +01:00
template.rst Add Gerrit Topic to the spec template 2015-03-03 11:18:10 -08:00
test-requirements.txt Update requirements for Sphinx 1.5 2017-03-02 19:11:26 +01:00
tox.ini Move from oslosphinx to openstackdocstheme 2019-05-15 08:14:34 -05:00

Infra Specs Repository

This is a git repository for doing design review on enhancements to the OpenStack Project Infrastructure. This provides an ability to ensure that everyone has signed off on the approach to solving a problem early on.

Expected Work Flow

  1. Create a story in StoryBoard with a task affecting the opendev/infra-specs project
  2. Propose a change to this repository and make sure Task: #<taskid> for the corresponding story's initial task is included as a footer in the commit message (see CONTRIBUTING.rst for relevant documentation links). This change should also add an entry for the proposed spec document in the Approved Design Specifications section of the doc/source/index.rst file.
  3. Once proposed, members of the community provide feedback through code review, and the specification should be revised until there seems to be some reasonable consensus as to its fitness.
  4. When ready for final approval, request addition of a call for votes to the weekly infra meeting agenda.
  5. If agreed by the meeting attendees, the chair will announce an approval deadline before which members of the Infrastructure Council are asked to cast their roll call votes on the proposal under review.

Once a specification is approved...

  1. Update the story, copying summary text of specification to there.
  2. Leave a comment linking to the published URL of the specification on the specs site.

Revisiting Specifications

We don't always get everything right the first time. If we realize we need to revisit a specification because something changed, either we now know more, or a new idea came in which we should embrace, we'll manage this by proposing an update to the specification in question.