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.
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?
