Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.
In particular, the s390-specific network devices currently are: ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.
This improves user experience, serviceability, maintainability, and reduces test effort.
Changes since v1: Addressed review comments from Philipp: * Replaced first paragraph (dracut commit reference) of patch 1 description with a summary of this cover letter providing URLs to 2 pull requests for dracut and s390utils with relevant commit titles. * Put temp file under subdir ${_DRACUT_KDUMP_NM_TMP_DIR}. My own changes: * Patch 2 description now also references the s390utils pull request with relevant commit title to provide further information regarding migration of znet persistent config from the old to the new scheme.
Steffen Maier (2): dracut-module-setup: consolidate s390 network device config (#1937048) dracut-module-setup: remove old s390 network device config (#1937048)
dracut-module-setup.sh | 53 ++++++++++++++---------------------------- 1 file changed, 17 insertions(+), 36 deletions(-)
base-commit: 5058cef90c2e24ff3a17a9c5560e16363e3281f5
This is a preparation for consolidating s390 network device config with https://github.com/dracutdevs/dracut/pull/2534 ("feat(znet): use zdev for consolidated device configuration") https://github.com/steffen-maier/s390utils/pull/1/commits ("znet: migrate to consolidated persistent device config with zdev (#1937046,#1937048))" ("znet: clean up old deprecated persistent device config (#1937046,#1937048)"). With above consolidation, s390-specific low-level configuration information will no longer be in NetworkManager connections (nor ifcfg files), but in the persistent configuration database of chzdev from s390-tools.
Since the kdump dracut module here depends on the "znet" dracut module [1] and "znet" will copy all persistent configuration into initrd as of above commit, all s390-specific information would already be in the kdump initrd. [1] 08de71252814 ("Move some dracut module dependencies checks to module-setup.sh"), 7148c0a30dfc ("add s390x netdev setup")
However, it is more appropriate and also removes the copy dependency from "znet" to introduce the consolidated zdev mechanism for importing just the required network device config from the current active system configuration. It does not depend on any of the pull requests above. It does not depend on any existing persistent configuration and can replace the old function code. This is similar to dracut block device dependency handling in s390-tools zdev/dracut/95zdev-kdump.
The old code only seems to work if there is exactly one s390-specific nmconnection (or ifcfg file). Related commits: b5577c163aff ("Simplify setup_znet by copying connection profile to initrd"), 7d472515688f ("Iterate /sys/bus/ccwgroup/devices to tell if we should set up rd.znet"), 8b08b4f17ba0 ("Set up s390 znet cmdline by "nmcli --get-values""), ce0305d4f95c ("Add a new option 'rd.znet_ifname' in order to use it in udev rules"), 7148c0a30dfc ("add s390x netdev setup").
A bonding or teaming setup would have multiple following network interfaces, each of which would need a low-level config if they're s390 channel-attached network devices. The new code should be able to handle that by iterating the involved network interfaces. Chzdev only exports something if it's a device type it deems itself responsible for.
Additional debugging output can be generated with e.g. dracut option "--stdlog 5" (or short -L5). It shows the chzdev export result, the output of chzdev export and import, and an overview of the resulting persistent config within the initrd. On systems, which default to using dracut option "--quiet", you might need an additional "--verbose" to counter "--quiet" so -L5 has effect. Typically combined with "--debug" to get a shell trace from building an initrd (Note: --debug does not increase the log levels).
Signed-off-by: Steffen Maier maier@linux.ibm.com --- dracut-module-setup.sh | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index ff53d084a9f0..7d92e84a7c3d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -26,6 +26,9 @@ check() { if [[ -z $IN_KDUMP ]] || [[ ! -f /etc/kdump.conf ]]; then return 1 fi + if [[ "$(uname -m)" == "s390x" ]]; then + require_binaries chzdev || return 1 + fi return 0 }
@@ -474,6 +477,8 @@ _find_znet_nmconnection() { # # Note part of code is extracted from ccw_init provided by s390utils kdump_setup_znet() { + local _netif + local _tempfile=$(mktemp --tmpdir="$_DRACUT_KDUMP_NM_TMP_DIR" kdump-dracut-zdev.XXXXXX) local _config_file _unique_name _NM_conf_dir local __sed_discard_ignored_files='/(~|.bak|.old|.orig|.rpmnew|.rpmorig|.rpmsave)$/d'
@@ -481,6 +486,18 @@ kdump_setup_znet() { return fi
+ for _netif in $1; do + chzdev --export "$_tempfile" --active --by-interface "$_netif" \ + 2>&1 | ddebug + sed -i -e 's/^[active /[persistent /' "$_tempfile" + ddebug < "$_tempfile" + chzdev --import "$_tempfile" --persistent --base "/etc=$initdir/etc" \ + --yes --no-root-update --force 2>&1 | ddebug + lszdev --configured --persistent --info --by-interface "$_netif" \ + --base "/etc=$initdir/etc" 2>&1 | ddebug + done + rm -f "$_tempfile" + _NM_conf_dir="/etc/NetworkManager/system-connections"
_config_file=$(_find_znet_nmconnection "$initdir/$_NM_conf_dir" "$__sed_discard_ignored_files") @@ -572,7 +589,7 @@ kdump_install_net() { if [[ -n "$_netifs" ]]; then kdump_install_nmconnections apply_nm_initrd_generator_timeouts - kdump_setup_znet + kdump_setup_znet "$_netifs" kdump_install_nm_netif_allowlist "$_netifs" kdump_install_nic_driver "$_netifs" fi
Hi Steffen,
On Thu, Nov 09, 2023 at 04:50:39PM +0100, Steffen Maier wrote:
This is a preparation for consolidating s390 network device config with https://github.com/dracutdevs/dracut/pull/2534
Does it mean the dracut PR depends on this patch?
When looking at the dracut PR, I notice there are some code of 95znet dracut module seeming to duplicate what this patch is doing because this kdump dracut module depends on the 95znet module,
if [[ $hostonly ]]; then local _tempfile _tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX) { chzdev qeth --export - --configured --persistent --quiet --type chzdev lcs --export - --configured --persistent --quiet --type chzdev ctc --export - --configured --persistent --quiet --type } 2> /dev/null > "$_tempfile" ddebug < "$_tempfile" chzdev --import "$_tempfile" --persistent --base "/etc=$initdir/etc" \ --yes --no-root-update --force 2>&1 | ddebug lszdev --configured --persistent --info \ --base "/etc=$initdir/etc" 2>&1 | ddebug rm -f "$_tempfile" ...
Does the above code will make all hostonly devices' configuration persistent? If the answer is yes, the code in the 95znet dracut module seems to interfere with what this patch is doing.
Hi Coiby,
On 1/15/24 07:57, Coiby Xu wrote:
On Thu, Nov 09, 2023 at 04:50:39PM +0100, Steffen Maier wrote:
This is a preparation for consolidating s390 network device config with https://github.com/dracutdevs/dracut/pull/2534
Does it mean the dracut PR depends on this patch?
I double checked and I don't think the dracut PR depends on the kdump code changes here. They are independent.
Only https://github.com/steffen-maier/s390utils/pull/1 depends on this particular code change here. And s390utils/pull/1 also depends on: https://github.com/dracutdevs/dracut/pull/2534, and https://github.com/storaged-project/blivet/pull/1162, which is paired together with https://github.com/rhinstaller/anaconda/pull/5250.
When looking at the dracut PR, I notice there are some code of 95znet dracut module seeming to duplicate what this patch is doing because this kdump dracut module depends on the 95znet module,
if [[ $hostonly ]]; then local _tempfile _tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX) { chzdev qeth --export - --configured --persistent --quiet --type chzdev lcs --export - --configured --persistent --quiet --type chzdev ctc --export - --configured --persistent --quiet --type } 2> /dev/null > "$_tempfile" ddebug < "$_tempfile" chzdev --import "$_tempfile" --persistent --base "/etc=$initdir/etc" \ --yes --no-root-update --force 2>&1 | ddebug lszdev --configured --persistent --info \ --base "/etc=$initdir/etc" 2>&1 | ddebug rm -f "$_tempfile" ...
Does the above code will make all hostonly devices' configuration persistent?
If hostonly mode is set (the case for kdump; kdump even uses strict hostonly mode), then all znet persistent configurations from zdev on the root-fs are exported and imported into the generated kdump initrd. So the answer is yes.
Above code is a compromise the avoid regressions in environments using / having used https://github.com/dracutdevs/dracut/blob/4980bad34775da715a2639b736cba5e65a... and potentially having established an implicit dependency on its old behavior: mostly copying the config of all (channel-attached) s390 network devices from root-fs into initrd (I neglect the check with has_carrier() for simplicity) [cf. the description of commits ("feat(znet): use zdev for consolidated device configuration") and ("feat(qeth_rules): remove qeth handling consolidated in 95znet") in the dracut PR]. Strictly speaking, 95qeth_rules and its consolidated successor 95znet from the dracut PR should only include persistent s390 network device config into any initrd (rootfs or kdump) for just those devices actually required to mount the root-fs or kdump target. To allow such code change in the future, the 99kdumpbase change here is coded to be independent of 95znet, so it does not depend on 95znet, which I think is also for a slightly different use case -- see below. But then again, we typically do not have as many network devices as we have disk devices, so it's OK to configure the same set of network devices in early initrd as we configure after the initrd switch root step.
If the answer is yes, the code in the 95znet dracut module seems to interfere with what this patch is doing.
My understanding is that dracut's 95znet handles network device(s) required to mount the root-fs or kdump target. Where the kdump target is on a network-attached block device (such as iSCSI) or on a network file system (such as NFS).
Please correct me if I got it wrong: 99kdumpbase handles network device(s) required for a kdump target which is neither a block device nor a network file system but a remote host over ssh. I'm not aware that the latter case would be handled by core dracut and I suppose that's one of the reasons for having 99kdumpbase.
The set of devices handled by 95znet and 99kdumpbase could be different without overlap. They could also overlap or even be the same. That's not a problem, because the way chzdev is called by both dracut modules (after my consolidation changes) it merges "duplicate" configurations of the same device. Hence, the initrd finally only contains exactly one persistent config per device. So we prevent any dangerous or interfering duplicate configs, which could cause trouble.
FWIW, I have also extensively tested the fully integrated device config consolidation including the changes to: s390-tools (upstream), s390utils (downstream), kexec-tools, dracut, anaconda, and blivet. For both the root-fs mount prep case ("regular" initrd) as well as the kdump case (to block devices (dasd and zfcp) and to ssh remote host).
On Mon, Jan 15, 2024 at 05:19:24PM +0100, Steffen Maier wrote:
Hi Coiby,
Hi Steffen,
On 1/15/24 07:57, Coiby Xu wrote:
On Thu, Nov 09, 2023 at 04:50:39PM +0100, Steffen Maier wrote:
This is a preparation for consolidating s390 network device config with https://github.com/dracutdevs/dracut/pull/2534
Does it mean the dracut PR depends on this patch?
I double checked and I don't think the dracut PR depends on the kdump code changes here. They are independent.
Only https://github.com/steffen-maier/s390utils/pull/1 depends on this particular code change here. And s390utils/pull/1 also depends on: https://github.com/dracutdevs/dracut/pull/2534, and https://github.com/storaged-project/blivet/pull/1162, which is paired together with https://github.com/rhinstaller/anaconda/pull/5250.
When looking at the dracut PR, I notice there are some code of 95znet dracut module seeming to duplicate what this patch is doing because this kdump dracut module depends on the 95znet module,
if [[ $hostonly ]]; then local _tempfile _tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX) { chzdev qeth --export - --configured --persistent --quiet --type chzdev lcs --export - --configured --persistent --quiet --type chzdev ctc --export - --configured --persistent --quiet --type } 2> /dev/null > "$_tempfile" ddebug < "$_tempfile" chzdev --import "$_tempfile" --persistent --base "/etc=$initdir/etc" \ --yes --no-root-update --force 2>&1 | ddebug lszdev --configured --persistent --info \ --base "/etc=$initdir/etc" 2>&1 | ddebug rm -f "$_tempfile" ...
Does the above code will make all hostonly devices' configuration persistent?
If hostonly mode is set (the case for kdump; kdump even uses strict hostonly mode), then all znet persistent configurations from zdev on the root-fs are exported and imported into the generated kdump initrd. So the answer is yes.
Above code is a compromise the avoid regressions in environments using / having used https://github.com/dracutdevs/dracut/blob/4980bad34775da715a2639b736cba5e65a... and potentially having established an implicit dependency on its old behavior: mostly copying the config of all (channel-attached) s390 network devices from root-fs into initrd (I neglect the check with has_carrier() for simplicity) [cf. the description of commits ("feat(znet): use zdev for consolidated device configuration") and ("feat(qeth_rules): remove qeth handling consolidated in 95znet") in the dracut PR]. Strictly speaking, 95qeth_rules and its consolidated successor 95znet from the dracut PR should only include persistent s390 network device config into any initrd (rootfs or kdump) for just those devices actually required to mount the root-fs or kdump target. To allow such code change in the future, the 99kdumpbase change here is coded to be independent of 95znet, so it does not depend on 95znet, which I think is also for a slightly different use case -- see below. But then again, we typically do not have as many network devices as we have disk devices, so it's OK to configure the same set of network devices in early initrd as we configure after the initrd switch root step.
Thank for the explanation! The dracut PR says "Those module sets partly competed with each other and partly contradicted each other such as activating too many devices for a memory-limited kdump environment" so I thought there are use cases where memory consumption for kdump needs to be reduced.
And the word hostonly has different meaning for me. I thought all active znet devices will be enabled. Actually only persistent configurations will be imported into the kdump initrd according to my test.
So considering "we typically do not have as many network devices" and only persistent device is enabled, my guess is the 95znet module won't cause excess memory consumption. But it's still an issue, we can make 95znet support the --hostonly-nics argument. Currently when building a kdump image, dracut is called with an empty --hostonly-nics argument. So 95znet can enable no znet device when --hostonly-nics is empty.
If the answer is yes, the code in the 95znet dracut module seems to interfere with what this patch is doing.
My understanding is that dracut's 95znet handles network device(s) required to mount the root-fs or kdump target. Where the kdump target is on a network-attached block device (such as iSCSI) or on a network file system (such as NFS).
Please correct me if I got it wrong: 99kdumpbase handles network device(s) required for a kdump target which is neither a block device nor a network file system but a remote host over ssh. I'm not aware that the latter case would be handled by core dracut and I suppose that's one of the reasons for having 99kdumpbase.
99kdumpbase supports dumping to an nfs or ssh fs. For both cases, it needs to make sure the required network devices can be activated successfully. Ideally 99kdumpbase should be upstreamed and delegate as the work to dependent modules (95znet in this case) as much as possible!
The set of devices handled by 95znet and 99kdumpbase could be different without overlap. They could also overlap or even be the same. That's not a problem, because the way chzdev is called by both dracut modules (after my consolidation changes) it merges "duplicate" configurations of the same device. Hence, the initrd finally only contains exactly one persistent config per device. So we prevent any dangerous or interfering duplicate configs, which could cause trouble.
FWIW, I have also extensively tested the fully integrated device config consolidation including the changes to: s390-tools (upstream), s390utils (downstream), kexec-tools, dracut, anaconda, and blivet. For both the root-fs mount prep case ("regular" initrd) as well as the kdump case (to block devices (dasd and zfcp) and to ssh remote host).
Thank you for your efforts of extensively testing the fully integrated consolidation!
In conclusion, I don't see a problem with this patch set and will merge it. Thank you for clearing up my confusion!
-- Mit freundlichen Gruessen / Kind regards Steffen Maier
Linux on IBM Z and LinuxONE
https://www.ibm.com/privacy/us/en/ IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Wolfgang Wendt Geschaeftsfuehrung: David Faller Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Since the previous commit reworks znet configuration to be based on the active system configuration, there is no dependency on any existing persistent configuration any more. Hence the old code handling systems with exactly one s390-specific nmconnection as persistent configuration can be removed.
Migration of the old persistent device configuration mechanism with nmconnections (or ifcfg) to zdev is handled independently in s390utils. [https://github.com/steffen-maier/s390utils/pull/1/commits ("znet: migrate to consolidated persistent device config with zdev (#1937046,#1937048))"]
Signed-off-by: Steffen Maier maier@linux.ibm.com --- dracut-module-setup.sh | 36 ------------------------------------ 1 file changed, 36 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 7d92e84a7c3d..070c17266d8c 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -467,20 +467,10 @@ kdump_setup_vlan() { _save_kdump_netifs "$_parent_netif" }
-_find_znet_nmconnection() { - LANG=C grep -s -E -i -l \ - "^s390-subchannels=([0-9].[0-9].[a-f0-9]+;){0,2}" \ - "$1"/*.nmconnection | LC_ALL=C sed -e "$2" -} - # setup s390 znet -# -# Note part of code is extracted from ccw_init provided by s390utils kdump_setup_znet() { local _netif local _tempfile=$(mktemp --tmpdir="$_DRACUT_KDUMP_NM_TMP_DIR" kdump-dracut-zdev.XXXXXX) - local _config_file _unique_name _NM_conf_dir - local __sed_discard_ignored_files='/(~|.bak|.old|.orig|.rpmnew|.rpmorig|.rpmsave)$/d'
if [[ "$(uname -m)" != "s390x" ]]; then return @@ -497,32 +487,6 @@ kdump_setup_znet() { --base "/etc=$initdir/etc" 2>&1 | ddebug done rm -f "$_tempfile" - - _NM_conf_dir="/etc/NetworkManager/system-connections" - - _config_file=$(_find_znet_nmconnection "$initdir/$_NM_conf_dir" "$__sed_discard_ignored_files") - if [[ -n "$_config_file" ]]; then - ddebug "$_config_file has already contained the znet config" - return - fi - - _config_file=$(LANG=C grep -s -E -i -l \ - "^[[:space:]]*SUBCHANNELS=['"]?([0-9].[0-9].[a-f0-9]+,){0,2}" \ - /etc/sysconfig/network-scripts/ifcfg-* \ - | LC_ALL=C sed -e "$__sed_discard_ignored_files") - - if [[ -z "$_config_file" ]]; then - _config_file=$(_find_znet_nmconnection "$_NM_conf_dir" "$__sed_discard_ignored_files") - fi - - if [[ -n "$_config_file" ]]; then - _unique_name=$(cat /proc/sys/kernel/random/uuid) - nmcli connection clone --temporary "$_config_file" "$_unique_name" &> >(ddebug) - nmcli connection modify --temporary "$_unique_name" connection.autoconnect false - inst "/run/NetworkManager/system-connections/${_unique_name}.nmconnection" "${_NM_conf_dir}/${_unique_name}.nmconnection" - nmcli connection del "$_unique_name" &> >(ddebug) - fi - }
kdump_get_remote_ip() {
For the series Reviewed-by: Philipp Rudo prudo@redhat.com
On Thu, 9 Nov 2023 16:50:38 +0100 Steffen Maier maier@linux.ibm.com wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.
In particular, the s390-specific network devices currently are: ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.
This improves user experience, serviceability, maintainability, and reduces test effort.
Changes since v1: Addressed review comments from Philipp:
- Replaced first paragraph (dracut commit reference) of patch 1 description with a summary of this cover letter providing URLs to 2 pull requests for dracut and s390utils with relevant commit titles.
- Put temp file under subdir ${_DRACUT_KDUMP_NM_TMP_DIR}.
My own changes:
- Patch 2 description now also references the s390utils pull request with relevant commit title to provide further information regarding migration of znet persistent config from the old to the new scheme.
Steffen Maier (2): dracut-module-setup: consolidate s390 network device config (#1937048) dracut-module-setup: remove old s390 network device config (#1937048)
dracut-module-setup.sh | 53 ++++++++++++++---------------------------- 1 file changed, 17 insertions(+), 36 deletions(-)
base-commit: 5058cef90c2e24ff3a17a9c5560e16363e3281f5
On 12/6/23 17:11, Philipp Rudo wrote:
For the series Reviewed-by: Philipp Rudo prudo@redhat.com
Thanks a lot, Philipp. Happy New Year. Hopefully I haven't missed anything, but assuming https://src.fedoraproject.org/rpms/kexec-tools/commits/rawhide would be the way into Fedora Rawhide, I could not find commits yet corresponding to my patch series (nor in https://gitlab.com/redhat/centos-stream/rpms/kexec-tools). My 2 patches do not depend on anything (new). They are a pre-req for some of the other pending pull requests for other packages. What can I do to get the kexec-tools patches into upstream/rawhide?
On Thu, 9 Nov 2023 16:50:38 +0100 Steffen Maier maier@linux.ibm.com wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.
In particular, the s390-specific network devices currently are: ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.
This improves user experience, serviceability, maintainability, and reduces test effort.
Changes since v1: Addressed review comments from Philipp:
- Replaced first paragraph (dracut commit reference) of patch 1 description with a summary of this cover letter providing URLs to 2 pull requests for dracut and s390utils with relevant commit titles.
- Put temp file under subdir ${_DRACUT_KDUMP_NM_TMP_DIR}.
My own changes:
- Patch 2 description now also references the s390utils pull request with relevant commit title to provide further information regarding migration of znet persistent config from the old to the new scheme.
Steffen Maier (2): dracut-module-setup: consolidate s390 network device config (#1937048) dracut-module-setup: remove old s390 network device config (#1937048)
dracut-module-setup.sh | 53 ++++++++++++++---------------------------- 1 file changed, 17 insertions(+), 36 deletions(-)
base-commit: 5058cef90c2e24ff3a17a9c5560e16363e3281f5
-- _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi Steffen,
Thanks for your patience!
On Thu, Nov 09, 2023 at 04:50:38PM +0100, Steffen Maier wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Although zdev exists, doesn't this patch set depend on a newer zdev? And I notice github.com/steffen-maier/s390utils/pull/1 hasn't been merged.
Hi Coiby,
thanks for your reply, much appreciated.
On 1/10/24 06:30, Coiby Xu wrote:
Thanks for your patience!
On Thu, Nov 09, 2023 at 04:50:38PM +0100, Steffen Maier wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Although zdev exists, doesn't this patch set depend on a newer zdev?
To the best of my knowledge, I only use old functionality of chzdev and lszdev. Do you have any particular code location / option in mind that might look like it needs something new?
I successfully tested this kexec-tools change standalone on an otherwise unmodified RHEL9, i.e. with whatever chzdev & lszdev it already ships packaged in s390utils-core (v2.27.0).
And I notice github.com/steffen-maier/s390utils/pull/1 hasn't been merged.
That only introduces helpers to migrate existing old persistent config to zdev persistent config, e.g. during distro upgrade, and gradually removes the Red Hat specific downstream code handling the old persistent config (no more parsing dasd.conf or zfcp.conf, not depending on s390-specific network device config in ifcfg files / NetworkManager connections). As such it will be one of the last things to be integrated. (Note that this PR cannot really be merged as there does not seem to be an "upstream" s390utils on github. I only opened this dangling PR as a shipment vehicle so Dan can take the commits from the branch of this PR, because I cannot use https://src.fedoraproject.org/rpms/s390utils to contribute.)
The full dependency graph of this entire endeavor of consolidating s390 device configuration is tricky. I think what matters here is that the kexec-tools change as well as the already merged https://github.com/ibm-s390-linux/s390-tools/pull/158 are both leave nodes in the dependency tree. I.e. they do not depend on anything else, but they are pre-reqs for other packages (or certains commits in PRs for other packages). This kexec-tools change here modifies the generation of host-specific znet device configuration stored in initrd during creation of a kdump initrd from the old persistent config to retrieving the necessary device configuration from the active config [sysfs] by only using old chzdev functionality. Hence it already becomes completely independent from the old persistent mechanism and thus does not need any migration of old persistent config => independent of s390utils/pull/1.
Hope this makes sense.
On Wed, Jan 10, 2024 at 03:24:30PM +0100, Steffen Maier wrote:
Hi Coiby,
thanks for your reply, much appreciated.
On 1/10/24 06:30, Coiby Xu wrote:
Thanks for your patience!
On Thu, Nov 09, 2023 at 04:50:38PM +0100, Steffen Maier wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Although zdev exists, doesn't this patch set depend on a newer zdev?
To the best of my knowledge, I only use old functionality of chzdev and lszdev. Do you have any particular code location / option in mind that might look like it needs something new?
It seems I don't have sufficient understanding about what the 1st patch is doing. Currently the low-level configuration is done by ccw_init which needs to extract info from NM (NetworkManager) connection files. Does I understand it correctly that there will be no need for invoke ccw_init after applying the 1st patch because the configuration is now persistent?
I successfully tested this kexec-tools change standalone on an otherwise unmodified RHEL9, i.e. with whatever chzdev & lszdev it already ships packaged in s390utils-core (v2.27.0).
Thank you for testing this change! To improve my understanding, I did an experiment by removing info like s390-subchannel from NM connection files. To my surprise, the network connection can be established successfully without applying this patch set for both RHEL8 and RHEL9? Is it expected?
And I notice github.com/steffen-maier/s390utils/pull/1 hasn't been merged.
That only introduces helpers to migrate existing old persistent config to zdev persistent config, e.g. during distro upgrade, and gradually removes the Red Hat specific downstream code handling the old persistent config (no more parsing dasd.conf or zfcp.conf, not depending on s390-specific network device config in ifcfg files / NetworkManager connections). As such it will be one of the last things to be integrated. (Note that this PR cannot really be merged as there does not seem to be an "upstream" s390utils on github. I only opened this dangling PR as a shipment vehicle so Dan can take the commits from the branch of this PR, because I cannot use https://src.fedoraproject.org/rpms/s390utils to contribute.)
The full dependency graph of this entire endeavor of consolidating s390 device configuration is tricky. I think what matters here is that the kexec-tools change as well as the already merged https://github.com/ibm-s390-linux/s390-tools/pull/158 are both leave nodes in the dependency tree. I.e. they do not depend on anything else, but they are pre-reqs for other packages (or certains commits in PRs for other packages). This kexec-tools change here modifies the generation of host-specific znet device configuration stored in initrd during creation of a kdump initrd from the old persistent config to retrieving the necessary device configuration from the active config [sysfs] by only using old chzdev functionality. Hence it already becomes completely independent from the old persistent mechanism and thus does not need any migration of old persistent config => independent of s390utils/pull/1.
Hope this makes sense.
Yes, it makes sense to me now. Thanks for such a detailed explanation!
-- Mit freundlichen Gruessen / Kind regards Steffen Maier
Linux on IBM Z and LinuxONE
https://www.ibm.com/privacy/us/en/ IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Wolfgang Wendt Geschaeftsfuehrung: David Faller Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jan 15, 2024 at 02:43:48PM +0800, Coiby Xu wrote:
I successfully tested this kexec-tools change standalone on an otherwise unmodified RHEL9, i.e. with whatever chzdev & lszdev it already ships packaged in s390utils-core (v2.27.0).
Thank you for testing this change! To improve my understanding, I did an experiment by removing info like s390-subchannel from NM connection files. To my surprise, the network connection can be established successfully without applying this patch set for both RHEL8 and RHEL9? Is it expected?
Oh, please ignore my question. I failed to notice for RHEL8/9 installations, the kdump kernel inherits the 1st kerne's rd.znet kernel parameter automatically.
On Mon, Jan 15, 2024 at 02:43:48PM +0800, Coiby Xu wrote:
On Wed, Jan 10, 2024 at 03:24:30PM +0100, Steffen Maier wrote:
Hi Coiby,
thanks for your reply, much appreciated.
On 1/10/24 06:30, Coiby Xu wrote:
Thanks for your patience!
On Thu, Nov 09, 2023 at 04:50:38PM +0100, Steffen Maier wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Although zdev exists, doesn't this patch set depend on a newer zdev?
To the best of my knowledge, I only use old functionality of chzdev and lszdev. Do you have any particular code location / option in mind that might look like it needs something new?
It seems I don't have sufficient understanding about what the 1st patch is doing. Currently the low-level configuration is done by ccw_init which needs to extract info from NM (NetworkManager) connection files. Does I understand it correctly that there will be no need for invoke ccw_init after applying the 1st patch because the configuration is now persistent?
Oh, please ignore this question as well. The answer is obvious since you've already tested the change.
Hi Steffen,
different question. We have an issue for persistent device configuration on s390 (RHEL-10545, IBM 191894). Does this series address this issue?
If so, do you have plans for backporting? Thing is that the window to include changes for 9.4 will close soon. So if the patches are meant to be included into 9.4 we need to hurry so our QE has a chance to take a look at it. Especially with the upcoming Chinese New Year holidays in mind.
Thanks Philipp
On Thu, 9 Nov 2023 16:50:38 +0100 Steffen Maier maier@linux.ibm.com wrote:
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework zdev from s390-tools.
This is part of a larger consolidation comprising: https://github.com/ibm-s390-linux/s390-tools/pull/158 https://github.com/dracutdevs/dracut/pull/2534 https://github.com/storaged-project/blivet/pull/1162 https://github.com/rhinstaller/anaconda/pull/5250 https://github.com/steffen-maier/s390utils/pull/1 However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.
In particular, the s390-specific network devices currently are: ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.
This improves user experience, serviceability, maintainability, and reduces test effort.
Changes since v1: Addressed review comments from Philipp:
- Replaced first paragraph (dracut commit reference) of patch 1 description with a summary of this cover letter providing URLs to 2 pull requests for dracut and s390utils with relevant commit titles.
- Put temp file under subdir ${_DRACUT_KDUMP_NM_TMP_DIR}.
My own changes:
- Patch 2 description now also references the s390utils pull request with relevant commit title to provide further information regarding migration of znet persistent config from the old to the new scheme.
Steffen Maier (2): dracut-module-setup: consolidate s390 network device config (#1937048) dracut-module-setup: remove old s390 network device config (#1937048)
dracut-module-setup.sh | 53 ++++++++++++++---------------------------- 1 file changed, 17 insertions(+), 36 deletions(-)
base-commit: 5058cef90c2e24ff3a17a9c5560e16363e3281f5
-
Coiby Xu -
Philipp Rudo -
Steffen Maier