[Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files.

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.
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 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
> 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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 

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