[Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files.
zhipengs.liu at intel.com
Tue Oct 16 02:23:26 UTC 2018
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.
I see that we already have post-patch script running mechanism.
This script will be copied to
After SW-UPDATE, it will be called by sw-patch-agent
From: Saul Wold [mailto:sgw at linux.intel.com]
Sent: 2018年10月16日 7:54
To: starlingx-discuss at 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
> 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.
I added additional review comments to these as well.
> Any concern? Welcome to add your comment and proposal!
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
More information about the Starlingx-discuss