Here are some answers to frequently-asked questions from IRC and elsewhere.
Using the ironic-dbsync revision
command, e.g:
$ cd ironic
$ tox -evenv -- ironic-dbsync revision -m \"create foo table\"
It will create an empty alembic migration. For more information see the alembic documentation.
Reno documentation contains a description of what can be added to each section of a release note. If, after reading this, you’re still unsure about whether to add a release note for your change or not, keep in mind that it is intended to contain information for deployers, so changes to unit tests or documentation are unlikely to require one.
By running reno
command via tox, e.g:
$ tox -e venv -- reno new version-foo
venv create: /home/foo/ironic/.tox/venv
venv installdeps: -r/home/foo/ironic/test-requirements.txt
venv develop-inst: /home/foo/ironic
venv runtests: PYTHONHASHSEED='0'
venv runtests: commands[0] | reno new version-foo
Created new notes file in releasenotes/notes/version-foo-ecb3875dc1cbf6d9.yaml
venv: commands succeeded
congratulations :)
$ git status
On branch test
Untracked files:
(use "git add <file>..." to include in what will be committed)
releasenotes/notes/version-foo-ecb3875dc1cbf6d9.yaml
Then edit the result file. Note that:
For more information see the reno documentation.
If this is a release note that pertains to something that was fixed on master or an intermediary release (during a development cycle, that hasn’t been branched yet), you can go ahead and update it by submitting a patch.
If it is the release note of an ironic release that has branched, it can be updated but we will only allow it in extenuating circumstances. (It can be updated by only updating the file in that branch. DO NOT update the file in master and cherry-pick it. If you do, see how the mess was cleaned up.)
You have an issue and would like a decision to be made. First, make sure that the issue hasn’t already been addressed, by looking at documentation, stories, specifications, or asking. Information and links can be found on the Ironic wiki page.
There are several ways to solicit comments and opinions:
If there are enough core folks at the weekly meeting, after discussing an issue, voting could happen and a decision could be made. The problem with IRC or the weekly meeting is that feedback will only come from the people that are actually present.
To inform (and solicit feedback from) more people about an issue, the preferred process is:
(This process was suggested in an email thread about process for making decisions.)
For more information, see the oslo.reports documentation page.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.