From 5676cbd92be1a9e6b75c0bfa3f155ae158a8771a Mon Sep 17 00:00:00 2001 From: zhipengl Date: Mon, 22 Oct 2018 18:16:28 +0000 Subject: [PATCH] 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 --- ...s-2003768-refactor-init-config-patches.rst | 262 ++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 specs/2019.03/approved/multi-os-2003768-refactor-init-config-patches.rst diff --git a/specs/2019.03/approved/multi-os-2003768-refactor-init-config-patches.rst b/specs/2019.03/approved/multi-os-2003768-refactor-init-config-patches.rst new file mode 100644 index 0000000..3f61a1c --- /dev/null +++ b/specs/2019.03/approved/multi-os-2003768-refactor-init-config-patches.rst @@ -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