Add priority efforts section

Add a section listing priority efforts.  Ensure that there is
exactly one spec listed for each priority effort.  Add stub specs
for efforts which predate the spec process.  Also, publish the
Gerrit search string to see all priority effort changes.

Remove the implemented/ directory so that spec URLs are stable
over time.  We have been linking to them very liberally, so let's
not codify workflow in URLs.

Remove the :glob: options so that specs now need to be listed
individually in the sections in which they should appear.  This
means that spec workflow involves changing the index page rather
than moving files (and URLs).

Change-Id: Ic7f088b7456d66f5ff164dea8504e1c5467bf79d
This commit is contained in:
James E. Blair 2015-05-14 15:30:50 -07:00
parent 23da7b76ed
commit c43e50b641
5 changed files with 244 additions and 28 deletions

View File

@ -7,41 +7,26 @@ the OpenStack Project Infrastructure. This provides an ability to
ensure that everyone has signed off on the approach to solving a
problem early on.
Repository Structure
====================
The expected structure of the respository is as follows::
specs/
implemented/
Expected Work Flow
==================
1. Create a story in StoryBoard with a task affecting the
``infra-specs`` project.
2. Propose review to infra-specs repository (ensure Story:<story number> is
in the commit message).
3. Leave a comment with the Gerrit address of the specification.
4. Bring forward the proposed item to the infra meeting for summary.
5. Review happens on proposal by infra-core members and others.
6. Iterate until review is Approved or Rejected.
2. Propose a change to infra-specs repository (ensure Story:<story
number> is in the commit message).
3. Leave a comment with the Gerrit URL of the specification.
4. Review happens on proposal by infra-core members and others.
5. When ready for final approval, bring forward the proposed item to
the infra meeting.
Once a specification is Approved...
Once a specification is approved...
1. Update story, copy summary text of specification to there.
2. Leave a comment to the git address of the specification.
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.
Learn As We Go
==============
This is a new way of attempting things, so we're going to be low in
process to begin with to figure out where we go from here. Expect some
early flexibility in evolving this effort over time.

View File

@ -1,21 +1,63 @@
Infrastructure Design Specifications
====================================
========================================================
OpenStack Project Infrastructure Design Specifications
========================================================
Priority Efforts
================
These are the efforts we focus our review attention on first. They
are a great way to get involved collaboratively with other
infrastructure developers.
.. toctree::
:maxdepth: 1
specs/logs-in-swift
specs/dib-nodepool
specs/openstackci
specs/migrate_to_zanata
Gerrit query for all changes related to priority efforts::
status:open AND (topic:enable_swift OR topic:dib-nodepool OR topic:zanata OR topic:downstream-puppet)
https://review.openstack.org/#/q/status:open+AND+%28topic:enable_swift+OR+topic:dib-nodepool+OR+topic:zanata+OR+topic:downstream-puppet%29,n,z
Approved Design Specifications
==============================
These are specifications that have been approved; work may or may not
have started on these. Reviewers will review related changes as time
permits.
.. toctree::
:glob:
:maxdepth: 1
specs/*
specs/doc-publishing
specs/nodepool-launch-workers
specs/nodepool-workers
specs/public_hiera
specs/storyboard_integration_tests
specs/storyboard_story_tags
specs/storyboard_subscription_pub_sub
specs/storyboard_task_branches
specs/zuul_split
Implemented Design Specifications
=================================
These specifications have already been implemented and are listed here
for historical purposes.
.. toctree::
:glob:
:maxdepth: 1
specs/implemented/*
specs/config-repo-split
specs/migrate_askbot
specs/puppet-modules
specs/server_base_template_refactor
specs/test-metrics-db
Specifications Repository Information

95
specs/dib-nodepool.rst Normal file
View File

@ -0,0 +1,95 @@
::
Copyright 2015 Hewlett-Packard Development Company, L.P.
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
=================================
Use Diskimage Builder in Nodepool
=================================
To ensure identical test environments in different clouds, use
Diskimage Builder to create images which are then uploaded to each
cloud used by Nodepool.
Problem Description
===================
Each cloud provider in use by Nodepool supplies different images which
can cause tests to perform differently.
Proposed Change
===============
Rather than try to correct the delta in each provider, create an image
locally that can be used in any provider and upload it to Glance.
Because it is difficult to use glance in all of its deployment
variations, move much of the cloud-interaction logic into the "shade"
library and use that to perform the uploads.
Alternatives
------------
Keep playing catch-up whenever clouds update their images.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
mordred
Gerrit Topic
------------
Use Gerrit topic "dib-nodepool" for all patches related to this spec.
.. code-block:: bash
git-review -t dib-nodepool
Work Items
----------
N/A
Repositories
------------
N/A
Servers
-------
N/A
DNS Entries
-----------
N/A
Documentation
-------------
N/A
Security
--------
N/A
Testing
-------
N/A
Dependencies
============
N/A

94
specs/logs-in-swift.rst Normal file
View File

@ -0,0 +1,94 @@
::
Copyright 2015 Hewlett-Packard Development Company, L.P.
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
=========================
Store Build Logs in Swift
=========================
Rather than store test build logs in a very large filesystem, store them
in swift.
Problem Description
===================
For a while, we have been storing test logs from builds in a very
large filesystem on static.openstack.org. It is not large enough to
store all of the data that we wish, and has already reached the
maximum capacity that we can allocate to it, and it incurs some system
administration overhead to maintain.
Proposed Change
===============
Store log files in Swift instead. Zuul will provide per-job
credentials to the workers based on the swift tempurl and formpost
facilities.
Alternatives
------------
Put logs in AFS or otherwise scale out the static filesystem solution.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
jhesketh
Gerrit Topic
------------
Use Gerrit topic "enable_swift" for all patches related to this spec.
.. code-block:: bash
git-review -t enable_swift
Work Items
----------
N/A
Repositories
------------
N/A
Servers
-------
N/A
DNS Entries
-----------
N/A
Documentation
-------------
N/A
Security
--------
N/A
Testing
-------
N/A
Dependencies
============
N/A