ec852a3fad
The most important bits are updating shade references to remove the openstack-infra. The other git urls will work through the redirect, but cleaning them up is just nicer. This removes two comments that reference files that no longer exist due to config generation. Also, fix some random use of github for cloning openstack repos, since the github mirror is best-effort only. Change-Id: I55a1d9db940cf5fa2c35421db7add015ae334563 Needed-By: https://review.opendev.org/654056
111 lines
4.0 KiB
ReStructuredText
111 lines
4.0 KiB
ReStructuredText
Bifrost is a part of Ironic, which is an OpenStack project and
|
|
thus follows OpenStack development procedures.
|
|
|
|
For a full (and official) description of the development workflow, see:
|
|
|
|
https://docs.openstack.org/infra/manual/developers.html#development-workflow
|
|
|
|
For a highly abridged version, read on.
|
|
|
|
-------------
|
|
Communicating
|
|
-------------
|
|
|
|
Before you file a bug or new review set, it's often helpful to chat with other
|
|
developers. The #openstack-ironic channel is a good place to start, and if
|
|
you don't have IRC (or would prefer email),
|
|
openstack-discuss@lists.openstack.org is the mailing list for all OpenStack
|
|
projects. As the name implies, that mailing list is for all OpenStack
|
|
development, so it's often harder to get attention on your particular issue.
|
|
|
|
-----------
|
|
Filing Bugs
|
|
-----------
|
|
|
|
Bugs should be filed in StoryBoard, not GitHub:
|
|
|
|
https://storyboard.openstack.org/#!/project/941
|
|
|
|
-----------------
|
|
Contributing Code
|
|
-----------------
|
|
|
|
Bifrost requires a valid OpenStack contributor agreement to be signed before
|
|
code can be accepted. Details can be found in the development workflow link
|
|
above.
|
|
|
|
Code isn't committed directly (so pull requests won't work); instead, the
|
|
code is submitted for review through Gerrit via git review, and once its
|
|
been sufficiently reviewed it will be merged from there.
|
|
|
|
Once that's done, the development workflow is, roughly::
|
|
|
|
$ git clone https://opendev.org/openstack/bifrost
|
|
$ cd bifrost
|
|
$ git checkout -b some-branch-name
|
|
... hack hack hack ...
|
|
$ git commit
|
|
$ git review
|
|
... The configuration details for this are in .gitreview.
|
|
... When the command runs, it will add a ChangeId to your commit
|
|
... message and print out a link for your reference
|
|
...
|
|
... If you need to fix something in that commit, you can do:
|
|
$ git commit --amend
|
|
$ git review
|
|
|
|
From that point on, the link the git review command generated is
|
|
the place to do final tweaks. When its approved, the code
|
|
will be merged in automatically.
|
|
|
|
If you propose a new feature and are unable to complete it, please
|
|
let the community know by commenting in the review set indicating
|
|
that someone else is free to carry on your change. If the core
|
|
reviewers observe reviews that are not being actively worked on,
|
|
we are likely to inquire with you. If a review is untouched and the
|
|
owner of the review is unreachable for a lengthy period of time,
|
|
such as three to six months, the core reviewers may abandon the
|
|
change as we do not utilize auto-abandon.
|
|
|
|
----------
|
|
Code Style
|
|
----------
|
|
|
|
Bifrost is a mix of Python, YaML, and bash thrown in for good measure.
|
|
|
|
The overall intent is to keep features, and changes simple to permit a user
|
|
to easily understand and extend bifrost to meet their operational needs as
|
|
we recognize needs may vary.
|
|
|
|
With this, we have a list of things that we would like people to keep in mind
|
|
when contributing code.
|
|
|
|
1. Try to limit YaML to 79 characters per row, we understand this is not
|
|
always possible, but please make an effort.
|
|
2. Try to keep change sets as short and to the point as possible.
|
|
3. Rather than pass key-value pair strings to Ansible modules, try to utilize
|
|
key-value pair lists on a module command line. Example::
|
|
|
|
- name: "Stat file for x reason"
|
|
stat:
|
|
file: '/path/to/file'
|
|
get_md5: no
|
|
|
|
4. Playbook conditionals utilizing variables intended as booleans,
|
|
should make use of the ``| bool`` casting feature. This is due
|
|
to command line overrides are typically interpreted as strings
|
|
instead of booleans. Example::
|
|
|
|
- name: "Something something something"
|
|
module:
|
|
parameter: "value"
|
|
when: boolean_value | bool == true
|
|
|
|
5. Be clear and explicit with actions in playbooks and comments.
|
|
6. Simplicity is favored over magic.
|
|
7. Documentation should generally be paired with code changes as we feel
|
|
that it is important for us to be able to release the master branch
|
|
at any time.
|
|
8. Documentation should always be limited to 79 characters per row.
|
|
9. If you have any questions, please ask in #openstack-ironic.
|