|tags:||used, for, groupings, and, indexing|
Update the date of your spec with the date that it was proposed. Add any tags to the spec that may be of use for people to get what its about at a glance.
Provide a synopsis as to why you are creating this spec/blueprint.
Introduction paragraph – why are we doing anything? A single paragraph of prose that operators can understand. Describe the problem in as much detail as you can.
Some notes about using this template:
A detailed description of the problem:
Provide an overview of the changes you’d like to see implemented. 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, if any, are the alternatives to the changes you are proposing? 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.
What impact will there be on the playbooks?
If this change set concerns any kind of upgrade process, describe how it is supposed to deal with that stuff. For example, if containers are removed and or have their specific purpose changed how do you indend to deal with the eventual upgrade from the prospective of an existing installation? Does this change require documentation to be fully supported or will there be specific tooling that has to be created in order for the upgrade to be completed?
Describe any potential security impact on the system. Some of the items to consider include:
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 firstname.lastname@example.org.
Describe any potential performance impact on the system. For example, how is the code executed and does it depend on upstream resources that may be unavailable?
Examples of things to consider here include:
How would the end user be impacted by this change? The “End User” is defined as the users of the deployed cloud?
How would the deployer be impacted by this change? Discuss things that will affect how OpenStack will be deployed, such as:
How does this change impact future developers working on the ansible playbooks? Discuss things that will affect other developers working on OS-Ansible-Deployment, such as:
Does this blueprint/spec depend one another blueprint or spec?
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.
Please add IRC nicknames where applicable.
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 discuss how the change will be tested. You should be able to answer the following questions:
What is the impact on the docs team of this change? Some changes might require donating resources to the docs team to have the documentation updated. Don’t repeat details discussed above, but please reference them here.
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: