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

[Saul Wold]

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/1nKnkweuxcqvVOoRcpnTYMVUUv1RoAugOWXMjB7VIrfc/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.
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.

> 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.
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.

> 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
>