blob: 47aea8e043fb93789bb8e8aa66870e88a096961b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
.. _CONTRIBUTING:
=================
How To Contribute
=================
Basics
======
#. Our source code is hosted on `OpenStack 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 launchpad_ blueprint 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 here_. For simple changes, contributors may optionally
add the text "TrivialFix" to the commit message footer to indicate to
reviewers a bug is not required.
.. _OpenStack Kolla Git: https://git.openstack.org/cgit/openstack/kolla/
.. _launchpad: https://bugs.launchpad.net/kolla
.. _here: https://wiki.openstack.org/wiki/GitCommitMessages
Please use the existing sandbox repository, available at
https://git.openstack.org/cgit/openstack-dev/sandbox, for learning, understanding
and testing the `Gerrit Workflow`_.
.. _Gerrit Workflow: https://docs.openstack.org/infra/manual/developers.html#development-workflow
Adding a new service
====================
Kolla aims to both containerise and deploy all services within the OpenStack
"big tent". 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 Docker best practices
(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 (e.g. mongodb) should inherit from ``base``.
Services consisting of only one service should be placed in an image named the
same as that service, e.g. ``horizon``. Services that consist of multiple
processes generally use a base image and child images, e.g. ``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
https://docs.openstack.org/kolla/latest/image-building.html#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::
FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
MAINTAINER {{ maintainer }}
{% 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 (e.g. glance-base).
|
