I think we should be ok with dropping patches to NTP config files from the packaging, leaving it to puppet instead. We’ll just want to make sure ntp is disabled upon initial install, which could be done in a kickstart, and enabled by puppet when the config file has been updated. We’ve added hooks in the installer/kickstart to call ntpdate during installation, so that the system time should be synced with the controller during initial install. We don’t generally update packaged config files in a patch. If we want to make customizations, we do it via puppet. All config files should be packaged as %config(noreplace), so any changes wouldn’t make it to a modified file anyway. Our goal for all thirdparty packages should be to have the packaged config file untouched, with necessary changes made via puppet. There should be few exceptions, like NFS, where we’d need changes to the config file before puppet runs. As for the puppet manifests, if there’s an existing manifest related to the config file you want to add, then it should be ok to modify an existing file. If not, you may need to add a new .pp file. And use of the ERB templates is preferred, as it generates the whole file in one shot, meaning it’s much cleaner if we need to apply or remove patches (no risk of stale data). Let me know if you have any questions. Or if anyone has a different opinion, feel free to comment. Cheers, Don. From: Liu, ZhipengS [mailto:zhipengs.liu@intel.com] Sent: Thursday, October 18, 2018 9:32 AM To: Liu, ZhipengS; Penney, Don Cc: starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Work on reducing config patch for ntp Hi Penny, Any comment on ntp? For nfs-utils, I have updated patch below. Could you pls help to review it? https://review.openstack.org/610459 I just used a new separate package (nfs-utils-config) instead of platform-utils to package Config files. Since the config file in nfs-utils is marked as %config(noreplace) , patching in future will Not overwrite it. So there is no issue for patching scenario. No need to use kickstart script and patching script for this case. Thanks for your proposal! Zhipeng From: Liu, ZhipengS [mailto:zhipengs.liu@intel.com] Sent: 2018年10月17日 17:11 To: Penney, Don <Don.Penney@windriver.com> Cc: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Work on reducing config patch for ntp Hi Penny, I’d like to discuss with you about this 2 patches. ntpd-started-no-g-option.patch //change /etc/sysconfig/ntpd ntp-spec-add-TiS-custom-config-files.patch // add ntp.conf file to /etc/ Can we remove this 2 patches? In stx/stx-config/puppet-manifests/src/modules/platform/manifests/ntp.pp, it already generates ntp.conf file by puppet file { 'ntp_config': ensure => file, path => '/etc/ntp.conf', mode => '0640', content => template('platform/ntp.conf.server.erb'), } For /etc/sysconfig/ntpd, I’d like to add this custom file in ntp.pp, then we can remove related patch. Any comment from you? Thanks! BTW, I saw some other packages also have pp file in stx/stx-config/puppet-manifests/src/modules/platform/manifests/ So I can do some modification on existed pp to change/add some config file, right? For SW patching scenario, it is OK for non-in-service update. After reboot, puppet will apply config again. But for in-service update, without reboot, how to apply this custom file again after patching. That’s why I thought of using patching-script. Do you have any other proposal? Thanks! zhipeng