Browse Source

(divingbell) Ansible framework

Change-Id: I42abea5a3763a8270925507e35be21089690bce3
changes/21/628221/12
Nishant Kumar 4 months ago
parent
commit
9ddbb75601
1 changed files with 154 additions and 0 deletions
  1. 154
    0
      specs/approved/divingbell_ansible_framework.rst

+ 154
- 0
specs/approved/divingbell_ansible_framework.rst View File

@@ -0,0 +1,154 @@
1
+..
2
+  This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+  License.
4
+
5
+  http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+.. index::
8
+   single: Divingbell
9
+   single: Ansible
10
+
11
+============================
12
+Divingbell Ansible Framework
13
+============================
14
+
15
+Ansible playbooks to achieve tasks for making bare metal changes
16
+for Divingbell target use cases.
17
+
18
+Links
19
+=====
20
+
21
+The work to author and implement this spec will be tracked under this `Storyboard Story`_
22
+
23
+Problem description
24
+===================
25
+
26
+Divingbell uses DaemonSets and complex shell scripting to make bare metal
27
+changes. This raises 2 problems:
28
+- Increasing number of DaemonSets on each host with increasing Divingbell
29
+usecases
30
+- Reinventing the wheel by writing complex shell scripting logic to make
31
+bare metal changes.
32
+
33
+Impacted components
34
+===================
35
+
36
+The following Airship components will be impacted by this solution:
37
+
38
+#. Divingbell: Introducing Ansible framework to make bare metal changes
39
+
40
+Proposed change
41
+===============
42
+
43
+This spec intends to introduce Ansible framework within Divingbell which is
44
+much simpler to make any bare metal configuration changes as compared to
45
+existing approach of writing complex shell scripting to achieve the same
46
+functionality.
47
+
48
+Adding playbook
49
+---------------
50
+
51
+Ansible playbooks should be written for making any configuration changes
52
+on the host.
53
+
54
+Existing shell script logic for making bare metal changes lives under
55
+``divingbell/templates/bin``, wherever applicable these should be replaced
56
+by newly written Ansible playbooks as described in the sections below.
57
+Ansible playbooks would be part of the Divingbell image.
58
+
59
+A separate directory structure needs to be created for adding the playbooks.
60
+Each Divingbell config can be a separate role within the playbook structure.
61
+
62
+::
63
+    - playbooks/
64
+        - roles/
65
+             - systcl/
66
+             - limits/
67
+        - group_vars
68
+             - all
69
+        - master.yml
70
+
71
+Files under ``group_vars`` should be loaded as a Kubernetes ``ConfigMap`` or
72
+``Secret`` inside the container. Existing entries in ``values.yaml`` for
73
+Divingbell should be used for populating the entries in the file under
74
+``group_vars``.
75
+
76
+This PS `Initial commit for Ansible framework`_ should be used as a reference
77
+PS for implementing the Ansibile framework.
78
+
79
+Ansible Host
80
+------------
81
+
82
+With Divingbell DaemonSet running on each host mounted at ``hostPath``,
83
+``hosts`` should be defined as given below within the ``master.yml``.
84
+
85
+::
86
+    hosts: all
87
+    connection: chroot
88
+
89
+Ansible chroot plugin should be used for making host level changes.
90
+`Ansible chroot plugin_`
91
+
92
+Divingbell Image
93
+----------------
94
+
95
+Dockerfile should be created containing the below steps:
96
+
97
+  - Pull base image
98
+  - Install Ansible
99
+  - Define working directory
100
+  - Copy the playbooks to the working directory
101
+
102
+Divingbell DaemonSets
103
+---------------------
104
+
105
+All the Divingbell DaemonSets that follow declarative and idempotent models
106
+should be replaced with a single DaemonSet. This DaemonSet will be
107
+responsible for populating required entries in ``group_vars`` as
108
+``volumeMounts``. Ansible command to run the playbook should be invoked from
109
+within the ``DaemonSet`` spec.
110
+
111
+The Ansible command to run the playbook should be invoked from within
112
+the ``DaemonSet`` spec.
113
+
114
+The Divingbell DaemonSet for ``exec`` module should be left out from this framework
115
+and it should keep functioning as a separate DaemonSet.
116
+
117
+Ansible Rollback
118
+----------------
119
+
120
+Rollback should be achieved via the ``update_site`` action i.e. if a playbook
121
+introduces a bad change into the environment then the recovery path would be to
122
+correct the change in the playbooks and run ``update_site`` with new changes.
123
+
124
+Security impact
125
+---------------
126
+
127
+None -  No new security impacts are introduced with this design.
128
+
129
+Performance impact
130
+------------------
131
+
132
+As this design reduces the number of DaemonSets being used within Divingbell,
133
+it will be an improvement in performance.
134
+
135
+Implementation
136
+==============
137
+
138
+This implementation should start off as a separate entity and not make
139
+parallel changes by removing the existing functonality.
140
+
141
+New Divingbell usecases can be first targetted with the Ansible framework
142
+while existing framework can co-exist with the new framework.
143
+
144
+Dependencies
145
+============
146
+
147
+Adds new dependency - Ansible framework.
148
+
149
+References
150
+==========
151
+
152
+.. _Storyboard Story: https://storyboard.openstack.org/#!/story/2004690
153
+.. _Initial commit for Ansible framework: https://review.openstack.org/#/c/639186/
154
+.. _Ansible chroot plugin: https://docs.ansible.com/ansible/latest/plugins/connection/chroot.html

Loading…
Cancel
Save