Wallaby opening

Move Victoria approved spces to implemented.

Move anything else ahead to Wallaby backlog.

Fix minor lint in ceph-benchmarking and cinder-ceph-replication
specs.

Change-Id: I49027bdbf23ef2a498fd1f2b3bf1b1770544f8f8
Co-authored-by: Aurelien Lourot <aurelien.lourot@canonical.com>

doc/source/index.rst

@@ -11,6 +11,7 @@ Here you can find the specs, and spec template, for each release:
    :glob:
    :maxdepth: 1
 
+   specs/wallaby/index
    specs/victoria/index
    specs/ussuri/index
    specs/train/index

doc/source/specs/victoria/index.rst

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

doc/source/specs/wallaby/approved

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

doc/source/specs/wallaby/backlog

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

doc/source/specs/wallaby/implemented

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

doc/source/specs/wallaby/index.rst

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

doc/source/specs/wallaby/redirects

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

doc/source/specs/wallaby/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/wallaby/backlog/ceph-benchmarking.rst

@@ -33,9 +33,9 @@ Problem Description
 
 It is often unclear what performance one should expect from a software stack
 like Ceph. For example, it is difficult to give performance expectations in
-absolute terms (e.g. IOPS, throuput, etc), because performance is hardware and technology
-dependent. It may also be difficult to determine which suite of features to use
-and what their relative cost / benefit quotient might be.
+absolute terms (e.g. IOPS, throuput, etc), because performance is hardware and
+technology dependent. It may also be difficult to determine which suite of
+features to use and what their relative cost / benefit quotient might be.
 
 The proposed changes will allow for acquiring relative performance (IOPs) on a
 given set of hardware that can be compared with various features turned on or

specs/wallaby/backlog/cinder-ceph-replication.rst

@@ -102,6 +102,25 @@ None
 Implementation
 ==============
 
+Assignee(s)
+-----------
+
+1. ionutbalutoiu (primary)
+2. oprinmarius
+
+Gerrit Topic
+------------
+
+Use Gerrit topic "cinder-ceph-replication" for all patches related to this
+spec.
+
+.. code-block:: bash
+
+    git-review -t cinder-ceph-replication
+
+Work Items
+----------
+
 - cinder-ceph
 
   - Provides a new config option ``rbd-mirror-mode`` (with the ``pool`` as the
@@ -143,22 +162,6 @@ Implementation
     This is going to be useful for charms that implement the ``ceph-client``
     interface, but the relation name is not ``ceph``.
 
-Assignee(s)
------------
-
-1. ionutbalutoiu (primary)
-2. oprinmarius
-
-Gerrit Topic
-------------
-
-Use Gerrit topic "cinder-ceph-replication" for all patches related to this
-spec.
-
-.. code-block:: bash
-
-    git-review -t cinder-ceph-replication
-
 Repositories
 ------------