From c0ab828e141222f923b3397a075d69bc3bdad492 Mon Sep 17 00:00:00 2001 From: Steven Hardy Date: Wed, 9 Sep 2015 15:19:11 +0100 Subject: [PATCH] Cleanup template files The juno/kilo templates are the same, and now we need a liberty one so just rename to "template.rst" Change-Id: I31ebf2ed034079e49b8ce036aa52d1bb1d8142e6 --- doc/source/conf.py | 3 +- specs/juno-template.rst | 208 ---------------------- specs/{kilo-template.rst => template.rst} | 0 tests/test_titles.py | 10 +- 4 files changed, 6 insertions(+), 215 deletions(-) delete mode 100644 specs/juno-template.rst rename specs/{kilo-template.rst => template.rst} (100%) diff --git a/doc/source/conf.py b/doc/source/conf.py index 7698d5fb..a7d9ebe3 100755 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -33,8 +33,7 @@ feed_base_url = 'http://specs.openstack.org/openstack/tripleo-specs' feed_author = 'OpenStack TripleO Team' exclude_patterns = [ - '**/juno-template.rst', - '**/kilo-template.rst', + '**/template.rst', ] # autodoc generation is a bit aggressive and a nuisance when doing heavy diff --git a/specs/juno-template.rst b/specs/juno-template.rst deleted file mode 100644 index f77974a5..00000000 --- a/specs/juno-template.rst +++ /dev/null @@ -1,208 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -========================================== -Example Spec - The title of your blueprint -========================================== - -Include the URL of your launchpad blueprint: - -https://blueprints.launchpad.net/tripleo - -Introduction paragraph -- why are we doing anything? A single paragraph of -prose that operators can understand. - -Some notes about using this template: - -* Your spec should be in ReSTructured text, like this template. - -* Please wrap text at 80 columns. - -* The filename in the git repository should match the launchpad URL, for - example a URL of: https://blueprints.launchpad.net/tripleo/+spec/awesome-thing - should be named awesome-thing.rst - -* 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, build the docs using tox, or see: - http://rst.ninjs.org - - -Problem Description -=================== - -A detailed description of the problem: - -* For a new feature this might be use cases. Ensure you are clear about the - actors in each use case: End User vs Deployer - -* For a major reworking of something existing it would describe the - problems in that feature that are being addressed. - - -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? - -Alternatives ------------- - -What other ways could we do this thing? Why aren't we using those? This doesn't -have to be a full literature review, but it should demonstrate that thought has -been put into why the proposed solution is an appropriate one. - -Security Impact ---------------- - -Describe any potential security impact on the system. Some of the items to -consider include: - -* Does this change touch sensitive data such as tokens, keys, or user data? - -* Does this change involve cryptography or hashing? - -* Does this change require the use of sudo or any elevated privileges? - -* Does this change involve using or parsing user-provided data? This could - be directly at the API level or indirectly such as changes to a cache layer. - -* Can this change enable a resource exhaustion attack, such as allowing a - single API interaction to consume significant server resources? Some examples - of this include launching subprocesses for each connection, or entity - expansion attacks in XML. - -For more detailed guidance, please see the OpenStack Security Guidelines as -a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These -guidelines are a work in progress and are designed to help you identify -security best practices. For further information, feel free to reach out -to the OpenStack Security Group at openstack-security@lists.openstack.org. - -Other End User Impact ---------------------- - -Are there ways a user will interact with this feature? - -Performance Impact ------------------- - -Describe any potential performance impact on the system, for example -how often will new code be called, and is there a major change to the calling -pattern of existing code. - -Examples of things to consider here include: - -* A small change in a utility function or a commonly used decorator can have a - large impacts on performance. - -Other Deployer Impact ---------------------- - -Discuss things that will affect how you deploy and configure OpenStack -that have not already been mentioned, such as: - -* What config options are being added? Should they be more generic than - proposed (for example a flag that other hypervisor drivers might want to - implement as well)? Are the default values ones which will work well in - real deployments? - -* Is this a change that takes immediate effect after its merged, or is it - something that has to be explicitly enabled? - -* Please state anything that those doing continuous deployment, or those - upgrading from the previous release, need to be aware of. Also describe - any plans to deprecate configuration values or features. For example, if we - change the directory name that instances are stored in, how do we handle - instance directories created before the change landed? Do we move them? Do - we have a special case in the code? Do we assume that the operator will - recreate all the instances in their cloud? - -Developer Impact ----------------- - -Discuss things that will affect other developers working on OpenStack. - - -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: - - -Other contributors: - - -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. - - -Dependencies -============ - -* Include specific references to specs and/or blueprints in tripleo, or in other - projects, that this one either depends on or is related to. - -* If this requires functionality of another project that is not currently used - by Tripleo (such as the glance v2 API when we previously only required v1), - document that fact. - -* Does this feature require any new library dependencies or code otherwise not - included in OpenStack? Or does it depend on a specific version of library? - - -Testing -======= - -Please discuss how the change will be tested. - -Is this untestable in CI given current limitations (specific hardware / -software configurations available)? If so, are there mitigation plans (3rd -party testing, gate enhancements, etc). - - -Documentation Impact -==================== - -What is the impact on the docs? Don't repeat details discussed above, but -please reference them here. - - -References -========== - -Please add any useful references here. You are not required to have any -reference. Moreover, this specification should still make sense when your -references are unavailable. Examples of what you could include are: - -* Links to mailing list or IRC discussions - -* Links to notes from a summit session - -* Links to relevant research, if appropriate - -* Related specifications as appropriate (e.g. if it's an EC2 thing, link the EC2 docs) - -* Anything else you feel it is worthwhile to refer to diff --git a/specs/kilo-template.rst b/specs/template.rst similarity index 100% rename from specs/kilo-template.rst rename to specs/template.rst diff --git a/tests/test_titles.py b/tests/test_titles.py index c65cce1c..2439a44c 100644 --- a/tests/test_titles.py +++ b/tests/test_titles.py @@ -86,13 +86,13 @@ class TestTitles(testtools.TestCase): def test_template(self): + with open("specs/template.rst") as f: + template = f.read() + spec = docutils.core.publish_doctree(template) + template_titles = self._get_titles(spec) + releases = [x.split('/')[1] for x in glob.glob('specs/*/')] for release in releases: - with open("specs/%s-template.rst" % release) as f: - template = f.read() - spec = docutils.core.publish_doctree(template) - template_titles = self._get_titles(spec) - files = glob.glob("specs/%s/*/*" % release) for filename in files: self.assertTrue(filename.endswith(".rst"),