[Starlingx-discuss] Work on reducing non-openstack patches that related to config/service/init files.
sgw at linux.intel.com
Mon Oct 15 23:54:28 UTC 2018
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
> 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.
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
More information about the Starlingx-discuss