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>
This commit is contained in:
zhipengl 2018-10-22 18:16:28 +00:00 committed by zhipeng liu
parent 7569733926
commit 5676cbd92b
1 changed files with 262 additions and 0 deletions

View File

@ -0,0 +1,262 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License. http://creativecommons.org/licenses/by/3.0/legalcode
http://creativecommons.org/licenses/by/3.0/legalcode
============================
Refactor init/config patches
============================
Storyboard: https://storyboard.openstack.org/#!/story/2003768
For package patches related to adding or changing StarlingX specific systemd
service files, configuration files or other types,
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.
if they need to change files delivered by the upstream RPM, use puppet to
change it instead of original patch.
Problem description
===================
There are many patches related to adding or changing init script, config file,
systemd service adding and changing. We'd better to do some refactor on these
patches and remove them, so that we can decrease total patch number and use
binary packages instead of source packages.
Use Cases
=========
There are totally 8 cases for all init/config patches.
1)Add configuration files to system folder.
2)Add scripts to system folder.
3)Add service files to /etc/systemd/system/.
4)Change configuration files with noreplace attribute in system folder
5)Change files including configuration file, script and service without
noreplace attribute in system folder.
6)Change service files in usr/lib/systemd/system/ that will be started by SM
after power on.
7)Change service files in usr/lib/systemd/system/ that will be started by
systemd after power on.
8)Already uses puppet instead of earlier patch, or paired patches exist that we
can rework and decrease unnecessary meta patch.
Proposed change
===============
Proposed solutions for all these cases except for case 5/6
1)Use configuration package
- Add a configuration package folder under the folder where the
original package sit. Name package like nfs-utils-config.
- Use this configuration package to package configuration files to
system folder.
- Add "requires: original package" in spec file like
“Requires: nfs-utils” to make sure original package is installed
before configuration package.
- If we need to add files, we can package customized files to system
folder.
- If we need to change files with noreplace, we can copy customized
files to "/usr/share/starlingx/stx.xxx.conf" first. Then in post
section of the spec, copy it to destination folder as xxx.conf
during initiation installation.
- For case 7, services are enabled by systemctl command in spec file.
We can package customized service file to /etc/systemd/system/,
like we did for memcached.
please refer to https://review.openstack.org/#/c/600868/
https://review.openstack.org/#/c/610459/
2)Use Puppet
This is the preferred method for updating configuration in existing
files.
- We can do some modifications on existed pp files in
stx/stx-config/puppet-manifests/src/modules/platform/manifests.
- For some basic configuration file change with “noreplace” attribute,
we can also add a pp file in above folder.
To use puppet, there are two things need to be care:
- Puppet will execute in each boot up, so the configuration file will
be overwritten. We need make sure the file will not be changed in
runtime. If the file will be changed in runtime, then we cannot use
puppet for it.
- Puppet will be executed based on node type. Also RPM will be
installed based on node type. Need to make sure both method align to
be executed in the same node type.
3)Rework current patches
Some META patches includes not only configuration related patch, but
also src patch or spec change like build flag.
After removing configuration change part out, we need rework Meta
patch.
Propose to use "spec-include-TiS-changes.patch" to include all spec
change or src related patch adding if there is no corresponding META
patch.
Proposed solutions for case 5 and 6
1) Change files including configuration file, script and service without
"noreplace" attribution in spec file.
Such as systemd, we need to change rule file, tmp.conf, tmp.mount and
so on.
If we change this kind of file to customized one without patch, after
in-service patching on this package, the file will be overwritten to
original one. How to handle this patching scenario? Any proposal?
From my point, we can utilize existed in-service patching-script
mechanism to call in-service script to copy customized file to
destination folder after patching. Any comment?
2) Change service files in usr/lib/systemd/system/ that will be started by
SM after power on.
Such as net-snmp, we have 3 meta patches related to snmpd.service
change.
We can disable service in post section of spec file if the service is
not disabled by default. Then it will be started by SM later.
Please refer to below google sheet of analysis on non-openstack init-config
patches
https://docs.google.com/spreadsheets/d/1ttEFreSHLoWrHVAvrFV9xMGghAVQmSfctkcD4n7
tT9w/edit#gid=0
Alternatives
============
NA
Data model impact
=================
NA
REST API impact
===============
NA
Security impact
===============
Current solution is just used for refactoring patches and use config package or
puppet to package or change init/config files instead of existed patches.
No obvious security impact.
Other end user impact
=====================
NA
Performance Impact
==================
NA
Other deployer impact
=====================
NA
Developer impact
=================
The target of this feature is separating configuration part apart from source
patch and try the best to decrease the number of patch. We will also get
benefit when we consider multi-OS support on StarlingX.
For new joining developers, when we do some changes that refer to configuration
file, please keep this idea in your mind.
Upgrade impact
===============
NA
Implementation
==============
We have splitted the work to some tasks by SRPM package and planned to get it
done package by package.
General steps is below.
1) Rework existed meta patch and remove the part for configuration that we have
analyzed.
2) Remove the patch that will not be used anymore.
3) Add configuration RPM package for corresponding package that we are working
on, or add puppet file or modify existed puppet file to implement the logic
that we did with patches before.
4) Rebuild and do deployment and related test to see if the change can work and
meet our expectation.
5) Submit patch and get it reviewed before code merge.
Assignee(s)
===========
Zhipeng Liu will leading the writing of the code.
Shuicheng lin will join the task as well.
Welcome other contributors join.
Primary assignee:
zhipengs
Other contributors:
Shuicheng
Repos Impacted
==============
openstack/stx-integ
Work Items
===========
There are more than 20 tasks created under story 2003768.
Dependencies
============
NA
Testing
=======
Basically, we will do deployment test and related configuration file check on
different node after power on and first reboot to see that if the configuration
file is expected in specific folders.
For configuration file change scenario, we need to do additional patching test
to see that if the configuration file is expected after patching.
For service file, we need to check service status after power on, reboot
or patching.
Documentation Impact
====================
NA
References
==========
NA
History
=======
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - 2019.03
- Introduced