Include the URL of your launchpad RFE:
https://bugs.launchpad.net/karbor/+bug/example-id
Introduction paragraph – why are we doing this feature? A single paragraph of prose that deployers, and developers, and operators can understand.
Do you even need to file a spec? Most features can be done by filing an RFE bug and moving on with life. In most cases, filing an RFE and documenting your design is sufficient. If the feature seems very large or contentious, then you may want to consider filing a spec.
A detailed description of the problem. What problem is this blueprint addressing?
What use cases does this address? What impact on actors does this change have? Ensure you are clear about the actors in each use case: Developer, End User, Deployer etc.
How do you propose to solve this problem?
This section is optional, and provides an area to discuss your high-level design at the same time as use cases, if desired. Note that by high-level, we mean the “view from orbit” rough cut at how things will happen.
This section should ‘scope’ the effort from a feature standpoint: how is the ‘Karbor end-to-end system’ going to look like after this change? What Karbor areas do you intend to touch and how do you intend to work on them?
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.
Describe any potential security impact on the system. Some of the items to consider include:
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:
Discuss things that will affect how you deploy and configure OpenStack that have not already been mentioned, such as:
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.
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.
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:
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.