Newer
Older
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
Customize an OpenStack Deployment
=================================
Kolla's Philosphy on Deployment
-------------------------------
Kolla has an objective to replace the inflexible, painful, resource intensive
deployment process of OpenStack with a flexible, painless, inexpensive
deployment process. Often to deploy OpenStack at one-hundred node scale that
a small business may require means building a team of OpenStack professionals
to maintain and manage the OpenStack deployment. Finding people experienced
in OpenStack deployment is very difficult and expensive, resulting in a big
barrier for OpenStack adoption. Kolla seeks to remedy this set of problems by
simplifying the deployment process but enabling flexible deployment models.
Kolla is a highly opinionated deployment tool out of the box. This permits
Kolla to be deployable with configuration of three key/value pairs. As an
operator's experience with OpenStack grows and the desire to customize
OpenStack services increases, Kolla offers full capability to override every
OpenStack service configuration option in the deployment.
The Kolla upstream community does not want to place key/value pairs in the
Ansible playbook configuration options that are not essential to obtaining
a functional deployment. If the Kolla upstream starts down the path of
templating configuration options, the Ansible configuration could conceivably
grow to hundreds of configuration key/value pairs which is unmanageable.
Further, as new versions of Kolla are released, there would be independent
customization available for different versions creating an unsupportable and
difficult to document environment. Finally, adding key/value pairs for
configuration options creates a situation in which a development and release
cycle is required in order to successfully add a new customization.
Essentially templating in configuration options is not a scalable solution
and would result in an inability of the project to execute its mission.
Kolla's Solution to Customization
---------------------------------
Rather then deal with the customization madness of templating configuration
options in Kolla's Ansible playbooks, Kolla eliminates all the inefficiencies
of existing deployment tools through a tidy simple design.
During deployment of an OpenStack service, a basic set of default configuration
options are merged with and overridden by custom ini configuration sections.
Kolla deployment customization is that simple! This does create a situation
in which the Operator references the upstream documentation if a customization
is desired in the OpenStack deployment. Fortunately the configuration options
documentation is extremely mature and well-formulated.
As an example, consider running Kolla in a virtual machine. In order to
launch virtual machines from Nova in a virtual environment, it is necessary
to use the QEMU hypervisor, rather then the KVM hypervisor. To achieve this
result, simply modify the file `/etc/kolla/config/nova/nova-compute.conf` and
add the contents::
[libvirt]
virt_type=qemu
After this change Kolla will use an emulated hypervisor with lower performance.
Kolla could have templated this commonly modified configuraiton option. If
Kolla starts down this path, the Kolla project could end with hundreds of
config options all of which would have to be subjectively evaluated for
inclusion or exclusion in the source tree.
Kolla's approach yields a solution which enables complete customization without
any upstream mainteance burden. Operators don't have to rely on a subjective
approval process for configuration options nor rely on a
developement/test/release cycle to obtain a desired customization. Instead
operators have ultimate freedom to make desired deployment choices immediately
without the approval of a third party.