Hi Saul and Brent, Really appreciate for your comment! Please see my inline comment. For case 3, sw update scenario. Furtherly, I'd like to do as below. Define a post-patch script RPM in below folder. cgcs-root/stx/stx-update/patch-scripts/ I see that we already have post-patch script running mechanism. This script will be copied to %_runtime_patch_scripts=/run/patching/patch-scripts After SW-UPDATE, it will be called by sw-patch-agent Thx! -Zhipeng -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: 2018年10月16日 7:54 To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files. On 10/15/2018 02:26 AM, Liu, ZhipengS wrote:

Hi all,

Recently I have analyzed all init patches of non-openstack patches that you can filter by "init" in "Analysis" column of below sheet https://docs.google.com/spreadsheets/d/1nKnkweuxcqvVOoRcpnTYMVUUv1RoAu gOWXMjB7VIrfc/edit#gid=1953568313 I have added my comments in column of "Comments from zhipeng"

1) The comments colored with blue means we can add service to /etc/systemd/system/ so that it can be started during power on. 2) The comments colored with orange means we can ADD config files or scripts to specific system folder. 3) The comments colored with green means we need to use our customized config files or scripts instead of default ones.

For both case 1 and 2 mentioned above, we just need to consider initial installation scenario. (22 patches) I worked out a method to remove related patches like below steps. a) Use platform-util RPM to copy all related config/service files to /tmp folder. Add config/service files to platform-util/centos/files/ Modify platform-util.spec to copy all related config/service files to /tmp folder. [Saul] I don't think we should put everything into one RPM, I would consider creating a new RPM per package, if a package as both a case 1 & case 2, they can go in the same RPM.

Ultimately, I think we need to break platform-utils down a little. For example the memcached.service should be moved to a stx-memcached RPM. Looking back I probably should have nacked that patch. [Zhipeng] Now, we already put memcached.service related copy script in platform-utils spec file. That's why I did the same for nfs-utils. As talked to you before, we can define %package for nfs-utils and other packages respectively, then build out different RPMs However, here we just use this platform-util spec to copy service to destination folder, is it really necessary to let it build out RPM for every third-party package. What's the purpose? @Brent also mentioned we'd better use tis-extensions. From the comment of tis-extensions below, it seems to be designed especially for this purpose. # # The tis-extensions group of packages is intended to allow us to # add files to "extend" thirdparty packages, such as by packaging # custom systemd files into /etc/systemd to override the originals # without modifying or rebuilding the thirdparty package. # So, for this point, could you help to get it aligned with Brent? Then we can start work on other patches soon.

b) Add a post-installation script to kickstart config file. (This script will be called by anaconda after software installation finished.) This post-installation script will copy config/service files to specific system folder. [Saul ]These should be individual scripts that are called by a standard mechanism from the kickstart post-install, this way they can be re-used by other software installers for Multi-OS support.

[Zhipeng] Yes! Currently, I just added the scriptlet in bsp-files/kickstarts/post_common.cfg. I'd like to add a new ks.cfg file like "bsp-files/kickstarts/post_3rdparty_package_install.cfg" to own this post-install script. ( KS_SCRIPT_POST) BTW, this is the standard mechanism that kickstart will parse this cfg file and get this post-script called after SW installation finished.

c) Then we can remove related patches.

For case 3, we need to consider both initial installation and SW update scenarios. (44 patches) a) Initial installation We can do the same as we do for case 1 and 2 b) SW update Add a post-update script that will be called by sw-patch-agent after sw update finished. Use post-update script to copy customized config files or scripts to specific system folders, overwrite default ones.

So far, I have started working on case 1 and 2, finished nfs-utils (Story: 2003768/Task: 26461) and verified deployment. You can review my patch below. https://review.openstack.org/#/c/610456/ https://review.openstack.org/#/c/610459/

I added additional review comments to these as well. Sau!

Any concern? Welcome to add your comment and proposal!

Thanks! Zhipeng

_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

Hi Penney, Thanks for your kind reply! See my inline comment. Thx! -Zhipeng -----Original Message----- From: Penney, Don [mailto:Don.Penney@windriver.com] Sent: 2018年10月16日 21:59 To: Liu, ZhipengS <zhipengs.liu@intel.com>; Saul Wold <sgw@linux.intel.com>; Rowsell, Brent <Brent.Rowsell@windriver.com> Cc: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files. Hi Zhipeng, Sorry, I was on vacation last week and have been playing catch-up. This patch script mechanism you're referring to is not for such purpose. It is for in-service patching only (no reboot patching), and is only for restarting services after a host has been patched and only if that host will not be rebooted as part of that patch. In fact, the StarlingX patching mechanism should not be part of your consideration here at all. [Zhipeng] Got clear! Why are you planning to copy files to a /tmp dir at all here, or using the kickstarts at all? I would see this effort as being one of the following: [zhipeng] As some patch also refers to changing the default config files and need to keep platform-util installed after nfs-utils(let custom files overwrite default ones) Instead, we can also use %require in platform-utils to keep this order. Service files: a) If we just want to append something to a packaged service file, create an override. For example, if we wanted to add an After=sw-patch.service to a system xyz.service file, we can package a file named /etc/systemd/system/xyz.service.d/add-sw-patch-dependency.conf that contains: [Unit] After=sw-patch.service b) If we want to completely replace a packaged system service file, like xyz.service, we can package our version to /etc/systemd/system/xyz.service [Zhipeng] How to package it, use platform-utils, or utilities/tis-extensions, or separate RPM to package config file to specific system folder. What's your preferred method or proposal? c) If we're patching a system package to make changes to a configuration file, we need to ask whether this change is necessary immediately upon installation, or whether the change can be made by puppet when the manifest is applied. Ideally, most cases should be the latter. If we believe it is the former, we'll need to consider other options, and ensure we can handle it in a way that will be patchable at runtime. [Zhipeng] Using puppet to change config file should be the same as script did, right? (Both copy our version configuration file to specific folder to overwrite default ones that are installed earlier) It still confuse me for sw update scenario, I'd like to get answer from you. For example if we change default configuration file of nfs-utils through script or puppet. After we upgrade nfs-utils to new version through sw-patch service. How to apply customized configuration file to it again? -----Original Message----- From: Liu, ZhipengS [mailto:zhipengs.liu@intel.com] Sent: Monday, October 15, 2018 10:23 PM To: Saul Wold; Rowsell, Brent Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files. Hi Saul and Brent, Really appreciate for your comment! Please see my inline comment. For case 3, sw update scenario. Furtherly, I'd like to do as below. Define a post-patch script RPM in below folder. cgcs-root/stx/stx-update/patch-scripts/ I see that we already have post-patch script running mechanism. This script will be copied to %_runtime_patch_scripts=/run/patching/patch-scripts After SW-UPDATE, it will be called by sw-patch-agent Thx! -Zhipeng -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: 2018年10月16日 7:54 To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files. On 10/15/2018 02:26 AM, Liu, ZhipengS wrote:

Hi all,

Recently I have analyzed all init patches of non-openstack patches that you can filter by "init" in "Analysis" column of below sheet https://docs.google.com/spreadsheets/d/1nKnkweuxcqvVOoRcpnTYMVUUv1RoAu gOWXMjB7VIrfc/edit#gid=1953568313 I have added my comments in column of "Comments from zhipeng"

1) The comments colored with blue means we can add service to /etc/systemd/system/ so that it can be started during power on. 2) The comments colored with orange means we can ADD config files or scripts to specific system folder. 3) The comments colored with green means we need to use our customized config files or scripts instead of default ones.

For both case 1 and 2 mentioned above, we just need to consider initial installation scenario. (22 patches) I worked out a method to remove related patches like below steps. a) Use platform-util RPM to copy all related config/service files to /tmp folder. Add config/service files to platform-util/centos/files/ Modify platform-util.spec to copy all related config/service files to /tmp folder. [Saul] I don't think we should put everything into one RPM, I would consider creating a new RPM per package, if a package as both a case 1 & case 2, they can go in the same RPM.

Ultimately, I think we need to break platform-utils down a little. For example the memcached.service should be moved to a stx-memcached RPM. Looking back I probably should have nacked that patch. [Zhipeng] Now, we already put memcached.service related copy script in platform-utils spec file. That's why I did the same for nfs-utils. As talked to you before, we can define %package for nfs-utils and other packages respectively, then build out different RPMs However, here we just use this platform-util spec to copy service to destination folder, is it really necessary to let it build out RPM for every third-party package. What's the purpose? @Brent also mentioned we'd better use tis-extensions. From the comment of tis-extensions below, it seems to be designed especially for this purpose. # # The tis-extensions group of packages is intended to allow us to # add files to "extend" thirdparty packages, such as by packaging # custom systemd files into /etc/systemd to override the originals # without modifying or rebuilding the thirdparty package. # So, for this point, could you help to get it aligned with Brent? Then we can start work on other patches soon.

b) Add a post-installation script to kickstart config file. (This script will be called by anaconda after software installation finished.) This post-installation script will copy config/service files to specific system folder. [Saul ]These should be individual scripts that are called by a standard mechanism from the kickstart post-install, this way they can be re-used by other software installers for Multi-OS support.

[Zhipeng] Yes! Currently, I just added the scriptlet in bsp-files/kickstarts/post_common.cfg. I'd like to add a new ks.cfg file like "bsp-files/kickstarts/post_3rdparty_package_install.cfg" to own this post-install script. ( KS_SCRIPT_POST) BTW, this is the standard mechanism that kickstart will parse this cfg file and get this post-script called after SW installation finished.

c) Then we can remove related patches.

For case 3, we need to consider both initial installation and SW update scenarios. (44 patches) a) Initial installation We can do the same as we do for case 1 and 2 b) SW update Add a post-update script that will be called by sw-patch-agent after sw update finished. Use post-update script to copy customized config files or scripts to specific system folders, overwrite default ones.

So far, I have started working on case 1 and 2, finished nfs-utils (Story: 2003768/Task: 26461) and verified deployment. You can review my patch below. https://review.openstack.org/#/c/610456/ https://review.openstack.org/#/c/610459/

I added additional review comments to these as well. Sau!

Any concern? Welcome to add your comment and proposal!

Thanks! Zhipeng

_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss