Open the Xena Specs

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

Change-Id: I1d86695f75773764bfed2cefe644c9fbbafed575

.gitignore

@@ -8,6 +8,7 @@ build
 *.swo
 *.pyc
 .stestr/
+.testrepository/
 
 # Files generated by JetBrains
-.idea/
+.idea/

doc/source/index.rst

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

doc/source/specs/victoria/approved

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

doc/source/specs/victoria/backlog

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

doc/source/specs/wallaby/backlog

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

doc/source/specs/wallaby/index.rst

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

doc/source/specs/xena/approved

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

doc/source/specs/xena/backlog

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

doc/source/specs/xena/implemented

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

doc/source/specs/xena/index.rst

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

doc/source/specs/xena/redirects

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

doc/source/specs/xena/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/xena/approved/ceph-dashboard.rst

@@ -42,7 +42,7 @@ supported on Ceph Octopus, OpenStack Victoria (and later) on Ubuntu 20.04 LTS.
 
 
 Out of Scope
-============
+------------
 
 The following items should be covered in any future work:
  - integration with current LMA stack solution
@@ -118,7 +118,7 @@ Documentation
 
 The charm should contain documented options:
 
-* Create charm options 
+* Create charm options
 
 * Create charm actions
 

specs/xena/approved/memory-fragmentation-tuning.rst

@@ -40,27 +40,27 @@ continuous 512 (2^9) 4K pages according to /proc/pagetypeinfo.
 
 2). Synchronous reclaim.
 There are three levels of watermark inside the system: 1). min 2). low 3).
-high. When the number of free pages lowers down to the low watermark. The kswapd
-will be wakened up to do the asynchronous reclaim. Furthermore, it will not be
-stopped until the number of free pages reaches the high watermark. However, when
-the memory allocation is strong enough, the free pages will continue to lower
-down to the min watermark. At this point, the number of min pages is reserved
-for emergency usage, and the allocation will go into the
+high. When the number of free pages lowers down to the low watermark. The
+kswapd will be wakened up to do the asynchronous reclaim. Furthermore, it
+will not be stopped until the number of free pages reaches the high watermark.
+However, when the memory allocation is strong enough, the free pages will
+continue to lower down to the min watermark. At this point, the number of min
+pages is reserved for emergency usage, and the allocation will go into the
 direct-reclaim (synchronous) mode. This will stall the process.
 
 Proposed Change
 ===============
 
-In the past experience, the 1GB gap between min<->low<->high watermark is a good
-practice in the server environment. The bigger gap can wake up the kswapd
+In the past experience, the 1GB gap between min<->low<->high watermark is a
+good practice in the server environment. The bigger gap can wake up the kswapd
 earlier and avoid the synchronous reclaim. Moreover, this can alleviate the
 latency. The sysctl parameters related to the watermark gap calculation:
 
 vm.min_free_kbytes
 vm.watermark_scale_factor
 
-For the Ubuntu kernel before 4.15 (Bionic), the only way to tune the watermark is
-to modify the vm.min_free_kbytes. The gap would be 1/4 of the
+For the Ubuntu kernel before 4.15 (Bionic), the only way to tune the watermark
+is to modify the vm.min_free_kbytes. The gap would be 1/4 of the
 vm.min_free_kbytes. However, increasing the min_free_kbytes is the minimum
 watermark reservation increase, which will decrease the actual memory that the
 runtime system can use.
@@ -77,7 +77,8 @@ The feature will be designed in flexible ways:
 off. For some small memory compute nodes (<32GB), the 1GB low memory is too
 many.
 
-2). The manual config has a higher priority to overwrite the default calculation.
+2). The manual config has a higher priority to overwrite the default
+calculation.
 
 Alternatives
 ------------
@@ -104,7 +105,8 @@ Primary assignee:
 Gerrit Topic
 ------------
 
-Use Gerrit topic "memory-fragmentation-tuning" for all patches related to this spec.
+Use Gerrit topic "memory-fragmentation-tuning" for all patches related to
+this spec.
 
 .. code-block:: bash
 
@@ -113,7 +115,8 @@ Use Gerrit topic "memory-fragmentation-tuning" for all patches related to this s
 Work Items
 ----------
 
-Implement the watermark_scale_factor value calculation to set up the gap to 1GB.
+Implement the watermark_scale_factor value calculation to set up the gap to
+1GB.
 
 Repositories
 ------------

test-requirements.txt

@@ -2,4 +2,4 @@
 # of appearance. Changing the order has an impact on the overall integration
 # process, which may cause wedges in the gate later.
 
-hacking>=3.0,<3.1.0 # Apache-2.0
+hacking>=3.0.1,<3.1.0 # Apache-2.0