Open the Antelope Specs

Open the Antelope cycle specs (a bit late, but better late than never).

Change-Id: I0a6be44a0b1d79ef54be0c5905734df5b032c4c7

doc/source/index.rst

@@ -11,6 +11,8 @@ Here you can find the specs, and spec template, for each release:
    :glob:
    :maxdepth: 1
 
+   specs/antelope/index
+   specs/zed/index
    specs/yoga/index
    specs/xena/index
    specs/wallaby/index

doc/source/specs/antelope/approved

@@ -0,0 +1 @@
+../../../../specs/antelope/approved

doc/source/specs/antelope/backlog

@@ -0,0 +1 @@
+../../../../specs/antelope/backlog

doc/source/specs/antelope/implemented

@@ -0,0 +1 @@
+../../../../specs/antelope/implemented

doc/source/specs/antelope/index.rst

@@ -0,0 +1,25 @@
+=============================
+Charm Antelope Specifications
+=============================
+
+Template:
+
+.. toctree::
+   :maxdepth: 1
+
+   Specification Template (Antelope release) <template>
+
+Antelope implemented specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+
+Antelope backlog (carried over from previous cycle) specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   backlog/*

doc/source/specs/antelope/redirects

@@ -0,0 +1 @@
+../../../../specs/antelope/redirects

doc/source/specs/antelope/template.rst

@@ -0,0 +1,125 @@
+..
+  Copyright <YEARS> <HOLDER>  <--UPDATE THESE
+
+  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
+
+===============================
+The Title of Your Specification
+===============================
+
+Introduction paragraph -- why are we doing anything?
+
+Problem Description
+===================
+
+A detailed description of the problem.
+
+Proposed Change
+===============
+
+Here is where you cover the change you propose to make in detail. How do you
+propose to solve this problem?
+
+If this is one part of a larger effort make it clear where this piece ends. In
+other words, what's the scope of this effort?
+
+What versions of the operating system are affected or required?
+
+What versions of OpenStack are affected or required?
+
+What version of Juju is required?
+
+Alternatives
+------------
+
+This is an optional section, where it does apply we'd just like a demonstration
+that some thought has been put into why the proposed approach is the best one.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Who is leading the writing of the code? Or is this a blueprint where you're
+throwing it out there to see who picks it up?
+
+If more than one person is working on the implementation, please designate the
+primary author and contact.
+
+Primary assignee:
+  <launchpad-id or None>
+
+Can optionally list additional ids if they intend on doing substantial
+implementation work on this blueprint.
+
+Gerrit Topic
+------------
+
+Use Gerrit topic "<topic_name>" for all patches related to this spec.
+
+.. code-block:: bash
+
+    git-review -t <topic_name>
+
+Work Items
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the timeline for implementation.
+
+Repositories
+------------
+
+Will any new git repositories need to be created?
+
+Identify all new charm repos, interface repos, layer repos, whether new or
+existing, which will be affected or involved directly in the work which is
+defined by this spec.
+
+Documentation
+-------------
+
+Will this require a documentation change?  If so, which documents?
+Will it impact developer workflow?  Will additional communication need
+to be made?
+
+Identify the surface area of doc updates explicitly, ie. charm-guide,
+deployment-guide, charm README, wiki page links.
+
+Security
+--------
+
+Does this introduce any additional security risks, or are there
+security-related considerations which should be discussed?
+
+Testing
+-------
+
+What tests will be available or need to be constructed in order to
+validate this?  Unit/functional tests, development
+environments/servers, etc.
+
+Are there any special hardware requirements to test this?
+
+Dependencies
+============
+
+- Include specific references to specs and/or stories, or in
+  other projects, that this one either depends on or is related to.
+
+- Does this feature require any new library or program dependencies
+  not already in use?
+
+- What are the plans to package and distribute the payload and/or
+  dependencies?

doc/source/specs/yoga/index.rst

@@ -15,19 +15,4 @@ Yoga implemented specs:
    :glob:
    :maxdepth: 1
 
-
-Yoga approved (but not implemented) specs:
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   approved/*
-
-Yoga backlog (carried over from previous cycle) specs:
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   backlog/*
+   implemented/*

doc/source/specs/zed/approved

@@ -0,0 +1 @@
+../../../../specs/zed/approved

doc/source/specs/zed/backlog

@@ -0,0 +1 @@
+../../../../specs/zed/backlog/

doc/source/specs/zed/implemented

@@ -0,0 +1 @@
+../../../../specs/zed/implemented

doc/source/specs/zed/index.rst

@@ -0,0 +1,18 @@
+=============================
+Charm Zed Specifications
+=============================
+
+Template:
+
+.. toctree::
+   :maxdepth: 1
+
+   Specification Template (Zed release) <template>
+
+Zed implemented specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   implemented/*

doc/source/specs/zed/redirects

@@ -0,0 +1 @@
+../../../../specs/zed/redirects

doc/source/specs/zed/template.rst

@@ -0,0 +1,125 @@
+..
+  Copyright <YEARS> <HOLDER>  <--UPDATE THESE
+
+  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
+
+===============================
+The Title of Your Specification
+===============================
+
+Introduction paragraph -- why are we doing anything?
+
+Problem Description
+===================
+
+A detailed description of the problem.
+
+Proposed Change
+===============
+
+Here is where you cover the change you propose to make in detail. How do you
+propose to solve this problem?
+
+If this is one part of a larger effort make it clear where this piece ends. In
+other words, what's the scope of this effort?
+
+What versions of the operating system are affected or required?
+
+What versions of OpenStack are affected or required?
+
+What version of Juju is required?
+
+Alternatives
+------------
+
+This is an optional section, where it does apply we'd just like a demonstration
+that some thought has been put into why the proposed approach is the best one.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Who is leading the writing of the code? Or is this a blueprint where you're
+throwing it out there to see who picks it up?
+
+If more than one person is working on the implementation, please designate the
+primary author and contact.
+
+Primary assignee:
+  <launchpad-id or None>
+
+Can optionally list additional ids if they intend on doing substantial
+implementation work on this blueprint.
+
+Gerrit Topic
+------------
+
+Use Gerrit topic "<topic_name>" for all patches related to this spec.
+
+.. code-block:: bash
+
+    git-review -t <topic_name>
+
+Work Items
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the timeline for implementation.
+
+Repositories
+------------
+
+Will any new git repositories need to be created?
+
+Identify all new charm repos, interface repos, layer repos, whether new or
+existing, which will be affected or involved directly in the work which is
+defined by this spec.
+
+Documentation
+-------------
+
+Will this require a documentation change?  If so, which documents?
+Will it impact developer workflow?  Will additional communication need
+to be made?
+
+Identify the surface area of doc updates explicitly, ie. charm-guide,
+deployment-guide, charm README, wiki page links.
+
+Security
+--------
+
+Does this introduce any additional security risks, or are there
+security-related considerations which should be discussed?
+
+Testing
+-------
+
+What tests will be available or need to be constructed in order to
+validate this?  Unit/functional tests, development
+environments/servers, etc.
+
+Are there any special hardware requirements to test this?
+
+Dependencies
+============
+
+- Include specific references to specs and/or stories, or in
+  other projects, that this one either depends on or is related to.
+
+- Does this feature require any new library or program dependencies
+  not already in use?
+
+- What are the plans to package and distribute the payload and/or
+  dependencies?

specs/antelope/backlog/cinder-nimblestorage.rst

@@ -37,8 +37,8 @@ are of condiderable importance for the development of this subordinate charm:
 * The new charm should implement all features currently existing in the cinder
   charm, regarding the nimblestorage functionality.
 
-Note that because the Nimblestorage driver is part of the cinder-common package, no
-additional packages need to be installed for this charm to work.
+Note that because the Nimblestorage driver is part of the cinder-common
+package, no additional packages need to be installed for this charm to work.
 
 This charm would be supported in the Ussuri release of Openstack and newer.
 
@@ -62,7 +62,8 @@ Secondary assignee:
 Gerrit Topic
 ------------
 
-Use Gerrit topic "charm-cinder-nimblestorage" for all patches related to this spec.
+Use Gerrit topic "charm-cinder-nimblestorage" for all patches related to this
+spec.
 
 .. code-block:: bash