Cleaned up all specs

Change to make the current specs pass the tox check as well as moved some
items around for better organization. All trailing whitespace was removed.

Change-Id: I51005d6e55172baf0afb939624dde57312e678ed
This commit is contained in:
Kevin Carter 2015-06-20 16:33:20 -05:00
parent 41fc1684ea
commit a81e567620
7 changed files with 69 additions and 50 deletions

View File

@ -1,5 +1,5 @@
Add PLUMgrid plugin to neutron playbooks
################################################################
########################################
:date: 2015-06-2 14:30
:tags: neutron, plugins, networking
@ -9,7 +9,7 @@ OpenStack Neutron Plugin through the os-ansible neutron playbooks.
* https://blueprints.launchpad.net/openstack-ansible/+spec/add-plumgrid-neutron-plugin
Problem Description
====================
===================
PLUMgrid is a core neutron networking plugin that has been a part of OpenStack
neutron since Grizzly. It offers a Network Virtualization Platform that uses
@ -31,14 +31,14 @@ APIs supported by the PLUMgrid plugin:
- Provider Networks
Proposed Change
====================
===============
This change is proposed to add the PLUMgrid plugin as a core plugin option
alongside ml2, which will be the default. This configurability should already
be achieved by the BP: modularize-neutron-plays.
The rest of the installation for PLUMgrid that requires PLUMgrid Controller and
Compute components, that enable management of the plugin, will be added
The rest of the installation for PLUMgrid that requires PLUMgrid Controller
and Compute components, that enable management of the plugin, will be added
externally through Ansible Galaxy roles.
The changes described below assume the previously mentioned BP modularization
@ -47,10 +47,11 @@ changes in place.
This feature is proposed for both kilo and juno branches, the juno change
will be carried out first:
1. For juno, parameters relevant to the PLUMgrid plugin, namely the plumgrid core
plugin and plugin config file, plumgrid.ini will be added to a new
dictionary item in 'neutron_plugins' in inventory/group_vars/neutron_all.yml
This will allow setting the 'neutron_plugin_type = plumgrid' if desired.
1. For juno, parameters relevant to the PLUMgrid plugin, namely the plumgrid
core plugin and plugin config file, plumgrid.ini will be added to a new
dictionary item in 'neutron_plugins' in
inventory/group_vars/neutron_all.yml This will allow setting the
'neutron_plugin_type = plumgrid' if desired.
2. For kilo, parameters relevant to the PLUMgrid plugin will be added to a
new dictionary item in 'neutron_plugins' in
@ -80,6 +81,10 @@ New templates will be added in the os_neutron role:
- playbooks/roles/os_neutron/templates/plugins/plumgrid/plumlib.ini
- playbooks/roles/os_neutron/files/rootwrap.d/plumlib.filters
Upgrade impact
--------------
None
Alternatives
------------
@ -120,6 +125,12 @@ Developer Impact
This change adds further installable options and as such does not
effect the default flow of the playbooks.
Dependencies
------------
None
Implementation
==============

View File

@ -1,5 +1,5 @@
Build Facts Archive
########################
###################
:date: 2015-04-23
:tags: archive, deployment, information

View File

@ -30,11 +30,11 @@ each file for differences and making informed decisions about what values to
take to ensure we have a production grade deployment system.
The approach to dealing with differences (eg changed defaults for a particular
setting) will be to use the kilo value where possible, adding an option to make
any changed setting tunable if it was not already. This gives the option to
users who are upgrading from juno to be able to reset a value back to the juno
default if desired, but also means that greenfield deployments of kilo use the
(hopefully better) kilo value.
setting) will be to use the kilo value where possible, adding an option to
make any changed setting tunable if it was not already. This gives the option
to users who are upgrading from juno to be able to reset a value back to the
juno default if desired, but also means that greenfield deployments of kilo use
the (hopefully better) kilo value.
Examples of configs impacted (these will differ depending on the service being
worked on)::
@ -49,9 +49,9 @@ worked on)::
Alternatives
------------
We could, wherever needed, preserve juno settings rather than taking forward the
kilo settings. This is potentially easier on users in an upgrade scenario, but
does mean that new users deploying kilo would get an already out of date
We could, wherever needed, preserve juno settings rather than taking forward
the kilo settings. This is potentially easier on users in an upgrade scenario,
but does mean that new users deploying kilo would get an already out of date
deployment. It also means that we miss an opportunity to implement best
practices deployments, instead sticking on old, less relevant, values.
@ -67,8 +67,8 @@ Upgrade impact
--------------
This change will impact upgrades, but upgrades are out of scope for this spec
which will be addressed separately. Largely it addresses greenfield deployments
of kilo.
which will be addressed separately. Largely it addresses greenfield
deployments of kilo.
Security impact
@ -84,8 +84,9 @@ Performance impact
------------------
Because the Kilo code base is not tested and released, the performance of the
stack will not be in scope at this time. As future work develops to finalize the
roles used in Kilo, work will be done on a per role basis to ensure performance.
stack will not be in scope at this time. As future work develops to finalize
the roles used in Kilo, work will be done on a per role basis to ensure
performance.
End user impact
@ -140,8 +141,8 @@ systems.
Documentation impact
====================
This change will likely have documentation impact. Specifically when documenting
changed values or deprecated config items.
This change will likely have documentation impact. Specifically when
documenting changed values or deprecated config items.
References

View File

@ -45,6 +45,11 @@ Playbook Impact
- playbooks/roles/os_neutron/tasks/neutron_post_install.yml
- playbooks/roles/os_neutron/defaults/main.yml
Upgrade Impact
--------------
None
Alternatives
------------
@ -123,7 +128,7 @@ A bit of additional documentation describing how to insert new plugins/agents
will be required. This will be deployer documentation.
References
====================
==========
N/A

View File

@ -24,9 +24,10 @@ class TestTitles(testtools.TestCase):
}
for node in section_tree:
if node.tagname == 'title':
section['name'] = node.rawsource
section['name'] = node.rawsource.lower()
elif node.tagname == 'section':
subsection = self._get_title(node)
subsection['name'] = subsection['name'].lower()
section['subtitles'].append(subsection['name'])
return section
@ -40,12 +41,12 @@ class TestTitles(testtools.TestCase):
def _check_titles(self, fname, titles):
expected_titles = [
'Problem description',
'Proposed change',
'Implementation',
'Testing',
'Documentation impact',
'References'
'problem description',
'proposed change',
'implementation',
'testing',
'documentation impact',
'references'
]
self.assertEqual(
sorted(expected_titles),
@ -53,28 +54,30 @@ class TestTitles(testtools.TestCase):
"Expected titles not found in document %s" % fname
)
proposed = 'Proposed change'
self.assertIn('Alternatives', titles[proposed])
self.assertIn('Dependencies', titles[proposed])
self.assertIn('Deployer impact', titles[proposed])
self.assertIn('Developer impact', titles[proposed])
self.assertIn('End user impact', titles[proposed])
self.assertIn('Performance impact', titles[proposed])
self.assertIn('Playbook impact', titles[proposed])
self.assertIn('Security impact', titles[proposed])
self.assertIn('Upgrade impact', titles[proposed])
impl = 'Implementation'
self.assertIn('Assignee(s)', titles[impl])
self.assertIn('Work items', titles[impl])
try:
proposed = 'proposed change'
self.assertIn('alternatives', titles[proposed])
self.assertIn('dependencies', titles[proposed])
self.assertIn('deployer impact', titles[proposed])
self.assertIn('developer impact', titles[proposed])
self.assertIn('end user impact', titles[proposed])
self.assertIn('performance impact', titles[proposed])
self.assertIn('playbook impact', titles[proposed])
self.assertIn('security impact', titles[proposed])
self.assertIn('upgrade impact', titles[proposed])
impl = 'implementation'
self.assertIn('assignee(s)', titles[impl])
self.assertIn('work items', titles[impl])
except Exception as exp:
raise SystemExit('Failed on file %s - Error %s' % (fname, exp))
def _check_lines_wrapping(self, tpl, raw):
for i, line in enumerate(raw.split("\n")):
if "http://" in line or "https://" in line:
continue
self.assertTrue(
len(line) < 80,
msg="%s:%d: Line limited to a maximum of 79 characters." %
len(line) <= 120,
msg="%s:%d: Line limited to a maximum of 120 characters." %
(tpl, i+1)
)
@ -99,7 +102,6 @@ class TestTitles(testtools.TestCase):
data = f.read()
spec = docutils.core.publish_doctree(data)
titles = self._get_titles(spec)
self._check_titles(filename, titles)
self._check_titles(filename, self._get_titles(spec))
self._check_lines_wrapping(filename, data)
self._check_no_cr(filename, data)