OpenStack Infrastructure Blueprint Repository
0a240e29fe
The only example of interpolated variables in the spec was in order to easily specify what kind of node should be used in a single-node job. Actually implementing the interpolation is not trivial, and this kind of interpolation adds some risk around making the configuration language more complicated, difficult to follow, and error-prone for users. Monty suggested that perhaps nodesets could become a first-class configuration option and negate the need for this particular example. That seems to work quite well -- allowing sets of nodes to be defined and referred to by name. Without this example to stand on, the variable interpolation feature doesn't seem worth it, at least at the moment. This change removes it and adds Nodesets as a configuration item. If we need it later, we can add it back. If we need a way to pass job variables to ansible, we can add a 'vars' job attribute, but treat it as a simple static structure, without interpolation. Change-Id: If2de49a698948279fb8deb88eb82bb4ae163f6b3 |
||
---|---|---|
doc/source | ||
specs | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
LICENSE | ||
MANIFEST.in | ||
README.rst | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
template.rst | ||
test-requirements.txt | ||
tox.ini |
Infra Specs Repository
This is a git repository for doing design review on enhancements to the OpenStack Project Infrastructure. This provides an ability to ensure that everyone has signed off on the approach to solving a problem early on.
Expected Work Flow
- Create a story in StoryBoard with a task
affecting the
infra-specs
project. - Propose a change to infra-specs repository (ensure Story:<story number> is in the commit message).
- Leave a comment on the story with the Gerrit URL of the specification.
- Review happens on proposal by infra-core members and others.
- When ready for final approval, bring forward the proposed item to the infra meeting.
Once a specification is approved...
- Update story, copy summary text of specification to there.
- Leave a comment to the git address of the specification.
Revisiting Specifications
We don't always get everything right the first time. If we realize we need to revisit a specification because something changed, either we now know more, or a new idea came in which we should embrace, we'll manage this by proposing an update to the specification in question.