================= How To Contribute ================= Basics ====== #. Our source code is hosted on `OpenDev Kolla Git `_. Bugs should be filed on `launchpad `_. #. Please follow OpenStack `Gerrit 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 `__ 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 `_. 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 `__ 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 `_, for learning, understanding and testing the `Gerrit Workflow `_. Adding a release note ===================== All new features should have a documented release note. To add a release note run the following command: .. code-block:: console tox -e venv -- reno new Typically in this project we do not add release notes for bug fixes. Upgrade notes can be extremely helpful for operators so these are encouraged. 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 `__ 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 `) 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).