Open for Ussuri release

Carry forward any backlog specs to Ussuri.

Carry forward any approved but still inflight specs to Ussuri.

Move implemented specs for Train to implemented folder.

Misc tidy of line lengths and missing titles in a couple of specs.

Run unit tests in gate under Python 3.

Change-Id: I23a8823568f1ac594982a37095f3e1c532b5ab53

.zuul.yaml

@@ -4,8 +4,8 @@
     check:
       jobs:
         - openstack-tox-pep8
-        - openstack-tox-py27
+        - openstack-tox-py37
     gate:
       jobs:
         - openstack-tox-pep8
-        - openstack-tox-py27
+        - openstack-tox-py37

doc/source/index.rst

@@ -14,6 +14,7 @@ on for the upcoming release. This is the output of those discussions:
    :glob:
    :maxdepth: 1
 
+   priorities/ussuri-priorities
    priorities/train-priorities
    priorities/stein-priorities
    priorities/rocky-priorities
@@ -31,6 +32,7 @@ Here you can find the specs, and spec template, for each release:
    :glob:
    :maxdepth: 1
 
+   specs/ussuri/index
    specs/train/index
    specs/stein/index
    specs/rocky/index

doc/source/specs/ussuri/approved

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

doc/source/specs/ussuri/backlog

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

doc/source/specs/ussuri/implemented

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

doc/source/specs/ussuri/index.rst

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

doc/source/specs/ussuri/redirects

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

doc/source/specs/ussuri/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/train/implemented/policy-d-override.rst

@@ -122,8 +122,8 @@ The charm will attempt some validation of the attached resource file:
 
 - That the file is a valid zip file (note that any directories are ignored.
   The zip file is flattened to remove directories.
-- Files that don't have a ``.yaml`` or ``.yml`` extension are ignored.  This allows
-  documentation to be added to the zip file.
+- Files that don't have a ``.yaml`` or ``.yml`` extension are ignored.  This
+  allows documentation to be added to the zip file.
 - The remaining, flattened, identified yaml files are checked to have unique
   names.  If not, then the validation fails.
 - Each file is (attempted to be) loaded using the Python yaml ``safe_load``
@@ -150,9 +150,10 @@ restarted.
 OpenStack Service Support
 -------------------------
 
-The policy override feature appeared in ``oslo.policy`` for the ocata release, and was picked up by
-keystone and nova initially.  In order for it to be supported, the OpenStack service needs to support
-the ``Enforcer`` class to be able to make use of the ``policy.d`` override directory (which is the
+The policy override feature appeared in ``oslo.policy`` for the ocata release,
+and was picked up by keystone and nova initially.  In order for it to be
+supported, the OpenStack service needs to support the ``Enforcer`` class to be
+able to make use of the ``policy.d`` override directory (which is the
 default).
 
 The following service projects (that have Canonical charms) examined and have
@@ -173,7 +174,8 @@ the ``Enforcer`` class at the queens release:
 - trove
 - zaqar
 
-The following service projects do not have ``Enforcer`` class support at present (stein):
+The following service projects do not have ``Enforcer`` class support at
+present (stein):
 
 - swift
 
@@ -200,6 +202,11 @@ for reactive charms.
 
 .. _`Bug#1741723`: https://bugs.launchpad.net/charm-keystone/+bug/1741723
 
+Alternatives
+------------
+
+N/A
+
 Implementation
 ==============
 
@@ -268,17 +275,17 @@ The following repositories will be affected:
 
 - `charm-helpers <https://github.com/juju/charm-helpers>`_
 - `charms.openstack <https://opendev.org/openstack/charms.openstack>`_
-- `cinder charm <https://opendev.org/openstack/charm-cinder>`_
-- `designate charm <https://opendev.org/openstack/charm-designate>`_
-- `glance charm <https://opendev.org/openstack/charm-glance>`_
-- `keystone charm <https://opendev.org/openstack/charm-keystone>`_
-- `neutron-api charm <https://opendev.org/openstack/charm-neutron-api>`_
-- `nova-cloud-controller charm <https://opendev.org/openstack/charm-nova-cloud-controller>`_
+- `cinder <https://opendev.org/openstack/charm-cinder>`_ charm
+- `designate <https://opendev.org/openstack/charm-designate>`_ charm
+- `glance <https://opendev.org/openstack/charm-glance>`_ charm
+- `keystone <https://opendev.org/openstack/charm-keystone>`_ charm
+- `neutron-api <https://opendev.org/openstack/charm-neutron-api>`_ charm
+- `nova-cloud-controller`_ charm
 
 And the testing frameworks:
 
 - `zaza <https://github.com/openstack-charmers/zaza>`_
-- `zaza-openstack-tests <in://github.com/openstack-charmers/zaza-openstack-tests>`_
+- `zaza-openstack-tests`_
 
 Documentation
 -------------
@@ -318,4 +325,9 @@ to drop appropriately formatted yaml files into the policy.d directory.
 Dependencies
 ============
 
-There are no dependencies.
+There are no dependencies
+
+.. LINKS
+
+.. _nova-cloud-controller: https://opendev.org/openstack/charm-nova-cloud-controller
+.. _zaza-openstack-tests: https:////github.com/openstack-charmers/zaza-openstack-tests

specs/ussuri/approved/ceph-fs-nfs-with-manilla.rst

@@ -110,6 +110,7 @@ A more complete bundle could look like:
         - manila:remote-manila-plugin
 
 Assignee(s)
+-----------
 
 Primary assignee:
   Chris.MacNaughton