[Community goal] Update the contributor guide
Co-authored-by: Radosław Piliszek <radoslaw.piliszek@gmail.com> Change-Id: I50e2bf6aac38624851edb15ecb108cade469ddad Story: #2007236 Task: #38531
This commit is contained in:
parent
629a2955f4
commit
f3f471b41e
19
CONTRIBUTING.rst
Normal file
19
CONTRIBUTING.rst
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
The source repository for this project can be found at:
|
||||||
|
|
||||||
|
https://opendev.org/openstack/kolla
|
||||||
|
|
||||||
|
Pull requests submitted through GitHub are **not** monitored.
|
||||||
|
|
||||||
|
To start contributing to OpenStack, follow the steps in the contribution guide
|
||||||
|
to set up and use Gerrit:
|
||||||
|
|
||||||
|
https://docs.openstack.org/contributors/code-and-documentation/quick-start.html
|
||||||
|
|
||||||
|
Bugs should be filed on Launchpad:
|
||||||
|
|
||||||
|
https://bugs.launchpad.net/kolla
|
||||||
|
|
||||||
|
For more specific information about contributing to this repository, see the
|
||||||
|
Kolla contributor guide:
|
||||||
|
|
||||||
|
https://docs.openstack.org/kolla/latest/contributor/contributing.html
|
@ -1,136 +0,0 @@
|
|||||||
=================
|
|
||||||
How To Contribute
|
|
||||||
=================
|
|
||||||
|
|
||||||
Basics
|
|
||||||
======
|
|
||||||
|
|
||||||
#. Our source code is hosted on `OpenDev Kolla Git
|
|
||||||
<https://opendev.org/openstack/kolla/>`_. Bugs should be filed on
|
|
||||||
`launchpad <https://bugs.launchpad.net/kolla>`_.
|
|
||||||
|
|
||||||
#. Please follow OpenStack `Gerrit Workflow
|
|
||||||
<https://docs.openstack.org/infra/manual/developers.html#development-workflow>`__
|
|
||||||
to contribute to Kolla.
|
|
||||||
|
|
||||||
#. Note the branch you're proposing changes to. ``master`` is the current focus
|
|
||||||
of development. Kolla project has a strict policy of only allowing backports
|
|
||||||
in ``stable/branch``, unless when not applicable. A bug in a
|
|
||||||
``stable/branch`` will first have to be fixed in ``master``.
|
|
||||||
|
|
||||||
#. Please file a `blueprint of kolla <https://blueprints.launchpad.net/kolla>`__
|
|
||||||
for any significant code change and a bug
|
|
||||||
for any significant bug fix. See how to reference a bug or a blueprint in
|
|
||||||
the `commit message <https://wiki.openstack.org/wiki/GitCommitMessages>`_.
|
|
||||||
For simple changes, contributors may optionally add the text "TrivialFix" to
|
|
||||||
the commit message footer to indicate to reviewers a bug is not required.
|
|
||||||
|
|
||||||
#. We use a `whiteboard <https://etherpad.openstack.org/p/KollaWhiteBoard>`__
|
|
||||||
to keep track of CI gate status, release status, stable backports, planning
|
|
||||||
and feature development status.
|
|
||||||
|
|
||||||
Please use the existing sandbox repository, available at `sandbox
|
|
||||||
<https://opendev.org/openstack-dev/sandbox>`_,
|
|
||||||
for learning, understanding and testing the `Gerrit Workflow
|
|
||||||
<https://docs.openstack.org/infra/manual/developers.html#development-workflow>`_.
|
|
||||||
|
|
||||||
Adding a release note
|
|
||||||
=====================
|
|
||||||
|
|
||||||
Kolla uses the following release notes sections:
|
|
||||||
|
|
||||||
- ``features`` --- for new features or functionality; these should ideally
|
|
||||||
refer to the blueprint being implemented;
|
|
||||||
- ``fixes`` --- for fixes closing bugs; these must refer to the bug being
|
|
||||||
closed;
|
|
||||||
- ``upgrade`` --- for notes relevant when upgrading from previous version;
|
|
||||||
these should ideally be added only between major versions; required when
|
|
||||||
the proposed change affects behaviour in a non-backwards compatible way or
|
|
||||||
generally changes something impactful;
|
|
||||||
- ``deprecations`` --- to track deprecated features; relevant changes may
|
|
||||||
consist of only the commit message and the release note;
|
|
||||||
- ``prelude`` --- filled in by the PTL before each release or RC.
|
|
||||||
|
|
||||||
Other release note types may be applied per common sense.
|
|
||||||
Each change should include a release note unless being a ``TrivialFix``
|
|
||||||
change or affecting only docs or CI. Such changes should `not` include
|
|
||||||
a release note to avoid confusion.
|
|
||||||
Remember release notes are mostly for end users which, in case of Kolla,
|
|
||||||
are OpenStack administrators/operators.
|
|
||||||
In case of doubt, the core team will let you know what is required.
|
|
||||||
|
|
||||||
To add a release note, run the following command:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
tox -e venv -- reno new <summary-line-with-dashes>
|
|
||||||
|
|
||||||
All release notes can be inspected by browsing ``releasenotes/notes``
|
|
||||||
directory.
|
|
||||||
|
|
||||||
To generate release notes in HTML format in ``releasenotes/build``, run:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
tox -e releasenotes
|
|
||||||
|
|
||||||
Note this requires the release note to be tracked by ``git`` so you
|
|
||||||
have to at least add it to the ``git``'s staging area.
|
|
||||||
|
|
||||||
Adding a new service
|
|
||||||
====================
|
|
||||||
|
|
||||||
Kolla aims to both containerise and deploy all services within the OpenStack
|
|
||||||
ecosystem. This is a constantly moving target as the ecosystem grows, so these
|
|
||||||
guidelines aim to help make adding a new service to Kolla a smooth experience.
|
|
||||||
|
|
||||||
The image
|
|
||||||
---------
|
|
||||||
|
|
||||||
Kolla follows `Best practices for writing Dockerfiles
|
|
||||||
<https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/>`__
|
|
||||||
when designing and implementing services where at all possible.
|
|
||||||
|
|
||||||
We use ``jinja2`` templating syntax to help manage the volume and complexity
|
|
||||||
that comes with maintaining multiple Dockerfiles for multiple different base
|
|
||||||
operating systems.
|
|
||||||
|
|
||||||
Images should be created under the ``docker`` directory. OpenStack services
|
|
||||||
should inherit from the provided ``openstack-base`` image, while supporting and
|
|
||||||
infrastructure services (for example, mongodb) should inherit from ``base``.
|
|
||||||
|
|
||||||
Services consisting of only one service should be placed in an image named the
|
|
||||||
same as that service, for example, ``horizon``. Services that consist of
|
|
||||||
multiple processes generally use a base image and child images, for example,
|
|
||||||
``glance-base``, ``glance-api``, and ``glance-registry``.
|
|
||||||
|
|
||||||
Jinja2 'blocks' are employed throughout the Dockerfile's to help operators
|
|
||||||
customise various stages of the build (refer to :ref:`Dockerfile Customisation
|
|
||||||
<dockerfile-customisation>`)
|
|
||||||
|
|
||||||
Some of these blocks are free form however, there are a subset that should be
|
|
||||||
common to every Dockerfile. The overall structure for a multi container service
|
|
||||||
is as follows:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
|
|
||||||
LABEL maintainer="{{ maintainer }}" name="{{ image_name }}" build-date="{{ build_date }}"
|
|
||||||
|
|
||||||
{% block << service >>_header %}{% endblock %}
|
|
||||||
|
|
||||||
{% import "macros.j2" as macros with context %}
|
|
||||||
|
|
||||||
<< binary specific steps >>
|
|
||||||
|
|
||||||
<< source specific steps >>
|
|
||||||
|
|
||||||
<< common steps >>
|
|
||||||
|
|
||||||
{% block << service >>_footer %}{% endblock %}
|
|
||||||
{% block footer %}{% endblock %}
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The generic footer block ``{% block footer %}{% endblock %}`` should not be
|
|
||||||
included in base images (for example, glance-base).
|
|
52
doc/source/contributor/adding-a-new-image.rst
Normal file
52
doc/source/contributor/adding-a-new-image.rst
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
==================
|
||||||
|
Adding a new image
|
||||||
|
==================
|
||||||
|
|
||||||
|
Kolla follows `Best practices for writing Dockerfiles
|
||||||
|
<https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/>`__
|
||||||
|
where at all possible.
|
||||||
|
|
||||||
|
We use ``jinja2`` templating syntax to help manage the volume and complexity
|
||||||
|
that comes with maintaining multiple Dockerfiles for multiple different base
|
||||||
|
operating systems.
|
||||||
|
|
||||||
|
Images should be created under the ``docker`` directory. OpenStack services
|
||||||
|
should inherit from the provided ``openstack-base`` image, and
|
||||||
|
infrastructure services (for example: ``fluentd``) should inherit from
|
||||||
|
``base``.
|
||||||
|
|
||||||
|
Projects consisting of only one service should be placed in an image named the
|
||||||
|
same as that service, for example: ``horizon``. Services that consist of
|
||||||
|
multiple processes generally use a base image and child images, for example:
|
||||||
|
``cinder-base``, ``cinder-api``, ``cinder-scheduler``, ``cinder-volume``,
|
||||||
|
``cinder-backup``.
|
||||||
|
|
||||||
|
Jinja2 `blocks` are employed throughout the Dockerfiles to help operators
|
||||||
|
customise various stages of the build (refer to :ref:`Dockerfile Customisation
|
||||||
|
<dockerfile-customisation>`)
|
||||||
|
|
||||||
|
Some of these blocks are free form. However, there is a subset that should be
|
||||||
|
common to every Dockerfile. The overall structure is as follows:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
|
||||||
|
LABEL maintainer="{{ maintainer }}" name="{{ image_name }}" build-date="{{ build_date }}"
|
||||||
|
|
||||||
|
{% block << service >>_header %}{% endblock %}
|
||||||
|
|
||||||
|
{% import "macros.j2" as macros with context %}
|
||||||
|
|
||||||
|
<< binary specific steps >>
|
||||||
|
|
||||||
|
<< source specific steps >>
|
||||||
|
|
||||||
|
<< common steps >>
|
||||||
|
|
||||||
|
{% block << service >>_footer %}{% endblock %}
|
||||||
|
{% block footer %}{% endblock %}
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The generic footer block ``{% block footer %}{% endblock %}`` should **not** be
|
||||||
|
included in base images (for example: ``cinder-base``).
|
125
doc/source/contributor/contributing.rst
Normal file
125
doc/source/contributor/contributing.rst
Normal file
@ -0,0 +1,125 @@
|
|||||||
|
============================
|
||||||
|
So You Want to Contribute...
|
||||||
|
============================
|
||||||
|
|
||||||
|
For general information on contributing to OpenStack, please check out the
|
||||||
|
`contributor guide <https://docs.openstack.org/contributors/>`_ to get started.
|
||||||
|
It covers all the basics that are common to all OpenStack projects: the
|
||||||
|
accounts you need, the basics of interacting with our Gerrit review system,
|
||||||
|
how we communicate as a community, etc.
|
||||||
|
|
||||||
|
Below will cover the more project specific information you need to get started
|
||||||
|
with Kolla.
|
||||||
|
|
||||||
|
Basics
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
|
The source repository for this project can be found at:
|
||||||
|
|
||||||
|
https://opendev.org/openstack/kolla
|
||||||
|
|
||||||
|
Communication
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
IRC Channel
|
||||||
|
``#openstack-kolla`` (`channel logs`_) on Freenode
|
||||||
|
|
||||||
|
Weekly Meetings
|
||||||
|
On Wednesdays at 15:00 UTC in the IRC channel (`meetings logs`_)
|
||||||
|
|
||||||
|
Mailing list (prefix subjects with ``[kolla]``)
|
||||||
|
http://lists.openstack.org/pipermail/openstack-discuss/
|
||||||
|
|
||||||
|
Meeting Agenda
|
||||||
|
https://wiki.openstack.org/wiki/Meetings/Kolla
|
||||||
|
|
||||||
|
Whiteboard (etherpad)
|
||||||
|
Keeping track of CI gate status, release status, stable backports,
|
||||||
|
planning and feature development status.
|
||||||
|
https://etherpad.openstack.org/p/KollaWhiteBoard
|
||||||
|
|
||||||
|
.. _channel logs: http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/
|
||||||
|
.. _meetings logs: http://eavesdrop.openstack.org/meetings/kolla/
|
||||||
|
|
||||||
|
Contacting the Core Team
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The list in alphabetical order (on first name):
|
||||||
|
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| Name | IRC nick | Email address |
|
||||||
|
+=======================+===============+====================================+
|
||||||
|
| `Christian Berendt`_ | berendt | berendt@betacloud-solutions.de |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Dincer Celik`_ | osmanlicilegi | hello@dincercelik.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Eduardo Gonzalez`_ | egonzalez | dabarren@gmail.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Jeffrey Zhang`_ | Jeffrey4l | jeffrey.zhang@99cloud.net |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Marcin Juszkiewicz`_ | hrw | marcin.juszkiewicz@linaro.org |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Mark Goddard`_ | mgoddard | mark@stackhpc.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Michał Nasiadka`_ | mnasiadka | mnasiadka@gmail.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Radosław Piliszek`_ | yoctozepto | radoslaw.piliszek@gmail.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Surya Prakash`_ | spsurya | singh.surya64mnnit@gmail.com |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
| `Cao Yuan`_ | caoyuan | cao.yuan@99cloud.net |
|
||||||
|
+-----------------------+---------------+------------------------------------+
|
||||||
|
|
||||||
|
.. _Christian Berendt: https://launchpad.net/~berendt
|
||||||
|
.. _Dincer Celik: https://launchpad.net/~osmanlicilegi
|
||||||
|
.. _Eduardo Gonzalez: https://launchpad.net/~egonzalez90
|
||||||
|
.. _Jeffrey Zhang: https://launchpad.net/~jeffrey4l
|
||||||
|
.. _Marcin Juszkiewicz: https://launchpad.net/~hrw
|
||||||
|
.. _Mark Goddard: https://launchpad.net/~mgoddard
|
||||||
|
.. _Michał Nasiadka: https://launchpad.net/~mnasiadka
|
||||||
|
.. _Radosław Piliszek: https://launchpad.net/~yoctozepto
|
||||||
|
.. _Surya Prakash: https://launchpad.net/~confisurya
|
||||||
|
.. _Cao Yuan: https://launchpad.net/~caoi-yuan
|
||||||
|
|
||||||
|
The current effective list is also available from Gerrit:
|
||||||
|
https://review.opendev.org/#/admin/groups/460,members
|
||||||
|
|
||||||
|
New Feature Planning
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
New features are discussed via IRC or mailing list (with [kolla] prefix).
|
||||||
|
Kolla project keeps blueprints in `Launchpad <https://blueprints.launchpad.net/kolla>`__.
|
||||||
|
Specs are welcome but not strictly required.
|
||||||
|
|
||||||
|
Task Tracking
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Kolla project tracks tasks in `Launchpad <https://bugs.launchpad.net/kolla>`__.
|
||||||
|
Note this is the same place as for bugs.
|
||||||
|
|
||||||
|
If you're looking for some smaller, easier work item to pick up and get started
|
||||||
|
on, search for the 'low-hanging-fruit' tag.
|
||||||
|
|
||||||
|
A more lightweight task tracking is done via etherpad - `Whiteboard <https://etherpad.openstack.org/p/KollaWhiteBoard>`__.
|
||||||
|
|
||||||
|
Reporting a Bug
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
You found an issue and want to make sure we are aware of it? You can do so
|
||||||
|
on `Launchpad <https://bugs.launchpad.net/kolla>`__.
|
||||||
|
Note this is the same place as for tasks.
|
||||||
|
|
||||||
|
Getting Your Patch Merged
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Most changes proposed to Kolla require two +2 votes from core reviewers before
|
||||||
|
+W. A release note is required on most changes as well. Release notes policy
|
||||||
|
is described in :ref:`its own section <release-notes>`.
|
||||||
|
|
||||||
|
Significant changes should have documentation and testing provided with them.
|
||||||
|
|
||||||
|
Project Team Lead Duties
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
All common PTL duties are enumerated in the `PTL guide <https://docs.openstack.org/project-team-guide/ptl.html>`_.
|
||||||
|
Kolla-specific PTL duties are listed in `Kolla PTL guide <https://docs.openstack.org/kolla/latest/contributor/ptl-guide.html>`_.
|
@ -12,7 +12,9 @@ We welcome everyone to join our project!
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
CONTRIBUTING
|
contributing
|
||||||
|
adding-a-new-image
|
||||||
|
release-notes
|
||||||
running-tests
|
running-tests
|
||||||
bug-triage
|
bug-triage
|
||||||
ptl-guide
|
ptl-guide
|
||||||
|
45
doc/source/contributor/release-notes.rst
Normal file
45
doc/source/contributor/release-notes.rst
Normal file
@ -0,0 +1,45 @@
|
|||||||
|
.. _release-notes:
|
||||||
|
|
||||||
|
=============
|
||||||
|
Release notes
|
||||||
|
=============
|
||||||
|
|
||||||
|
Kolla uses the following release notes sections:
|
||||||
|
|
||||||
|
- ``features`` --- for new features or functionality; these should ideally
|
||||||
|
refer to the blueprint being implemented;
|
||||||
|
- ``fixes`` --- for fixes closing bugs; these must refer to the bug being
|
||||||
|
closed;
|
||||||
|
- ``upgrade`` --- for notes relevant when upgrading from previous version;
|
||||||
|
these should ideally be added only between major versions; required when
|
||||||
|
the proposed change affects behaviour in a non-backwards compatible way or
|
||||||
|
generally changes something impactful;
|
||||||
|
- ``deprecations`` --- to track deprecated features; relevant changes may
|
||||||
|
consist of only the commit message and the release note;
|
||||||
|
- ``prelude`` --- filled in by the PTL before each release or RC.
|
||||||
|
|
||||||
|
Other release note types may be applied per common sense.
|
||||||
|
Each change should include a release note unless being a ``TrivialFix``
|
||||||
|
change or affecting only docs or CI. Such changes should `not` include
|
||||||
|
a release note to avoid confusion.
|
||||||
|
Remember release notes are mostly for end users which, in case of Kolla,
|
||||||
|
are OpenStack administrators/operators.
|
||||||
|
In case of doubt, the core team will let you know what is required.
|
||||||
|
|
||||||
|
To add a release note, run the following command:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
tox -e venv -- reno new <summary-line-with-dashes>
|
||||||
|
|
||||||
|
All release notes can be inspected by browsing ``releasenotes/notes``
|
||||||
|
directory.
|
||||||
|
|
||||||
|
To generate release notes in HTML format in ``releasenotes/build``, run:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
tox -e releasenotes
|
||||||
|
|
||||||
|
Note this requires the release note to be tracked by ``git`` so you
|
||||||
|
have to at least add it to the ``git``'s staging area.
|
Loading…
Reference in New Issue
Block a user