Browse Source

Adding spec: refactor init/config related non-openstack patches.

For RPM patches related to adding or changing StarlingX specific systemd
service files, configuration files or other types,
1)if they are not overwritting files already delivered by the upstream RPM,
  refactor and have an specific config rpm that delivers the new file instead
  of original patch.
2)if they need to change files delivered by the upstream RPM, use puppet to
  change it instead of original patch.

Story: 2003768

Change-Id: I3112ecebaec2e8e1531922e87036209f6acc61dd
Signed-off-by: zhipengl <zhipengs.liu@intel.com>
zhipengl 6 months ago
parent
commit
5676cbd92b

+ 262
- 0
specs/2019.03/approved/multi-os-2003768-refactor-init-config-patches.rst View File

@@ -0,0 +1,262 @@
1
+..
2
+  This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+  License. http://creativecommons.org/licenses/by/3.0/legalcode
4
+  http://creativecommons.org/licenses/by/3.0/legalcode
5
+
6
+============================
7
+Refactor init/config patches
8
+============================
9
+
10
+Storyboard: https://storyboard.openstack.org/#!/story/2003768
11
+
12
+For package patches related to adding or changing StarlingX specific systemd
13
+service files, configuration files or other types,
14
+if they are not overwritting files already delivered by the upstream RPM,
15
+refactor and have an specific config rpm that delivers the new file instead of
16
+original patch.
17
+if they need to change files delivered by the upstream RPM, use puppet to
18
+change it instead of original patch.
19
+
20
+Problem description
21
+===================
22
+
23
+There are many patches related to adding or changing init script, config file,
24
+systemd service adding and changing. We'd better to do some refactor on these
25
+patches and remove them, so that we can decrease total patch number and use
26
+binary packages instead of source packages.
27
+
28
+Use Cases
29
+=========
30
+
31
+There are totally 8 cases for all init/config patches.
32
+1)Add configuration files to system folder.
33
+2)Add scripts to system folder.
34
+3)Add service files to /etc/systemd/system/.
35
+4)Change configuration files with noreplace attribute in system folder
36
+5)Change files including configuration file, script and service without
37
+noreplace attribute in system folder.
38
+6)Change service files in usr/lib/systemd/system/ that will be started by SM
39
+after power on.
40
+7)Change service files in usr/lib/systemd/system/ that will be started by
41
+systemd after power on.
42
+8)Already uses puppet instead of earlier patch, or paired patches exist that we
43
+can rework and decrease unnecessary meta patch.
44
+
45
+Proposed change
46
+===============
47
+
48
+Proposed solutions for all these cases except for case 5/6
49
+1)Use configuration package
50
+
51
+        - Add a configuration package folder under the folder where the
52
+          original package sit. Name package like nfs-utils-config.
53
+
54
+        - Use this configuration package to package configuration files to
55
+          system folder.
56
+
57
+        - Add "requires: original package" in spec file like
58
+          “Requires: nfs-utils” to make sure original package is installed
59
+          before configuration package.
60
+
61
+        - If we need to add files, we can package customized files to system
62
+          folder.
63
+
64
+        - If we need to change files with noreplace, we can copy customized
65
+          files to "/usr/share/starlingx/stx.xxx.conf" first. Then in post
66
+          section of the spec, copy it to destination folder as xxx.conf
67
+          during initiation installation.
68
+
69
+        - For case 7, services are enabled by systemctl command in spec file.
70
+          We can package customized service file to /etc/systemd/system/,
71
+          like we did for memcached.
72
+
73
+        please refer to  https://review.openstack.org/#/c/600868/
74
+                         https://review.openstack.org/#/c/610459/
75
+
76
+2)Use Puppet
77
+
78
+        This is the preferred method for updating configuration in existing
79
+        files.
80
+
81
+        - We can do some modifications on existed pp files in
82
+          stx/stx-config/puppet-manifests/src/modules/platform/manifests.
83
+
84
+        - For some basic configuration file change with “noreplace” attribute,
85
+          we can also add a pp file in above folder.
86
+
87
+        To use puppet, there are two things need to be care:
88
+
89
+        - Puppet will execute in each boot up, so the configuration file will
90
+          be overwritten. We need make sure the file will not be changed in
91
+          runtime. If the file will be changed in runtime, then we cannot use
92
+          puppet for it.
93
+
94
+        - Puppet will be executed based on node type. Also RPM will be
95
+          installed based on node type. Need to make sure both method align to
96
+          be executed in the same node type.
97
+
98
+3)Rework current patches
99
+
100
+        Some META patches includes not only configuration related patch, but
101
+        also src patch or spec change like build flag.
102
+        After removing configuration change part out, we need rework Meta
103
+        patch.
104
+        Propose to use "spec-include-TiS-changes.patch" to include all spec
105
+        change or src related patch adding if there is no corresponding META
106
+        patch.
107
+
108
+Proposed solutions for case 5 and 6
109
+
110
+1)      Change files including configuration file, script and service without
111
+        "noreplace" attribution in spec file.
112
+        Such as systemd, we need to change rule file, tmp.conf, tmp.mount and
113
+        so on.
114
+        If we change this kind of file to customized one without patch, after
115
+        in-service patching on this package, the file will be overwritten to
116
+        original one. How to handle this patching scenario? Any proposal?
117
+        From my point, we can utilize existed in-service patching-script
118
+        mechanism to call in-service script to copy customized file to
119
+        destination folder after patching. Any comment?
120
+
121
+2)      Change service files in usr/lib/systemd/system/ that will be started by
122
+        SM after power on.
123
+        Such as net-snmp, we have 3 meta patches related to snmpd.service
124
+        change.
125
+        We can disable service in post section of spec file if the service is
126
+        not disabled by default. Then it will be started by SM later.
127
+
128
+Please refer to below google sheet of analysis on non-openstack init-config
129
+patches
130
+https://docs.google.com/spreadsheets/d/1ttEFreSHLoWrHVAvrFV9xMGghAVQmSfctkcD4n7
131
+tT9w/edit#gid=0
132
+
133
+Alternatives
134
+============
135
+
136
+NA
137
+
138
+Data model impact
139
+=================
140
+
141
+NA
142
+
143
+REST API impact
144
+===============
145
+
146
+NA
147
+
148
+Security impact
149
+===============
150
+
151
+Current solution is just used for refactoring patches and use config package or
152
+puppet to package or change init/config files instead of existed patches.
153
+No obvious security impact.
154
+
155
+Other end user impact
156
+=====================
157
+
158
+NA
159
+
160
+Performance Impact
161
+==================
162
+
163
+NA
164
+
165
+Other deployer impact
166
+=====================
167
+
168
+NA
169
+
170
+Developer impact
171
+=================
172
+
173
+The target of this feature is separating configuration part apart from source
174
+patch and try the best to decrease the number of patch. We will also get
175
+benefit when we consider multi-OS support on StarlingX.
176
+For new joining developers, when we do some changes that refer to configuration
177
+file, please keep this idea in your mind.
178
+
179
+Upgrade impact
180
+===============
181
+
182
+NA
183
+
184
+Implementation
185
+==============
186
+
187
+We have splitted the work to some tasks by SRPM package and planned to get it
188
+done package by package.
189
+General steps is below.
190
+1) Rework existed meta patch and remove the part for configuration that we have
191
+analyzed.
192
+
193
+2) Remove the patch that will not be used anymore.
194
+
195
+3) Add configuration RPM package for corresponding package that we are working
196
+   on, or add puppet file or modify existed puppet file to implement the logic
197
+   that we did with patches before.
198
+
199
+4) Rebuild and do deployment and related test to see if the change can work and
200
+   meet our expectation.
201
+
202
+5) Submit patch and get it reviewed before code merge.
203
+
204
+Assignee(s)
205
+===========
206
+
207
+Zhipeng Liu will leading the writing of the code.
208
+Shuicheng lin will join the task as well.
209
+Welcome other contributors join.
210
+
211
+Primary assignee:
212
+zhipengs
213
+
214
+Other contributors:
215
+Shuicheng
216
+
217
+Repos Impacted
218
+==============
219
+
220
+openstack/stx-integ
221
+
222
+Work Items
223
+===========
224
+
225
+There are more than 20 tasks created under story 2003768.
226
+
227
+Dependencies
228
+============
229
+
230
+NA
231
+
232
+Testing
233
+=======
234
+
235
+Basically, we will do deployment test and related configuration file check on
236
+different node after power on and first reboot to see that if the configuration
237
+file is expected in specific folders.
238
+For configuration file change scenario, we need to do additional patching test
239
+to see that if the configuration file is expected after patching.
240
+For service file, we need to check service status after power on, reboot
241
+or patching.
242
+
243
+Documentation Impact
244
+====================
245
+
246
+NA
247
+
248
+References
249
+==========
250
+
251
+NA
252
+
253
+History
254
+=======
255
+
256
+.. list-table:: Revisions
257
+   :header-rows: 1
258
+
259
+   * - Release Name
260
+     - Description
261
+   * - 2019.03
262
+     - Introduced

Loading…
Cancel
Save