Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Steffen maier zdev rebased #5927

Closed

Conversation

rvykydal
Copy link
Contributor

@rvykydal rvykydal commented Oct 9, 2024

The purpose of this PR is to check that some of the tests (for example rpm-build:fedora-rawhide-x86_64:anaconda-fedora ) pass on #5250 rebased to current anaconda. We may merge this PR rather then the original one if it does not get rebased.

…802482,#1937049)

Implements the dasd part of referenced bugs.

This allows to delegate s390-specifics to zdev from s390-tools and to
subsequently remove s390-specific code here.

Additionally, the change supports to subsequently solely rely on the zdev
persistent device configuration "database". Create entries on activating
devices. Simply copy the persistent device configuration to sysroot finally
without having to deal with device properties.

The spec file update reflects the new dependency on `chzdev` from the
s390 architecture specific sub-package s390utils-core. Actually, this
commit here only depends on `chzdev` in older versions already packaged
and shipped, so no version comparison necessary here.

Regarding unit test:

As blockdev was already mocked it's not clear how the test would mock
that sanitize_dev_input would actually canonicalize a DASD device bus-ID.

Also, the argument to execWithRedirect() is much more involved than just
the device bus-ID previously. It does not make sense for the unit test
to hard code the full argument of how execWithRedirect() is currently
invoked in the code.

So just check that the new code calls execWithRedirect() exactly once and
ignore the arguments.

It would be a separate fix patch to improve a fake sanitize unit test. I
suppose it would need to start with a DASD device bus-ID that is not yet
canonical/sanitized, e.g. something along the lines of:

DASDDiscoverTask("A100").run()
blockdev.s390.sanitize_dev_input.return_value = "0.0.A100"
blockdev.s390.sanitize_dev_input.assert_called_once_with("A100")
sanitized_input = blockdev.s390.sanitize_dev_input.return_value
execWithRedirect.assert_called_once_with(...)

It's unclear how much value that would have, though.

Signed-off-by: Steffen Maier <[email protected]>
…ot (#1802482,#1937049)

Implements a part of the referenced bugs.

Depends on
ibm-s390-linux/s390-tools@bc4f455
("zdev/dracut: retain early persistent config over switch root").
The spec file update reflects this new dependency on the new v2.31.0 of the
s390 architecture specific sub-package s390utils-core.

A new s390-tools zdev dracut module hook retain-zdev.sh copies the zdev
persistent configuration from the initrd into /run/zdev.initrd.config.
Import that persistent device configuration. It can be used:
* to transfer the configuration into the installed system.
* by python-blivet ZFCPDiskDevice.dracut_setup_args(),

Any s390 device configuration in the installer user interface produces
persistent zdev config entries.

Instead of treating each s390 device type differently, simply transfer the
entire combined resulting zdev persistent config into the installed system.

The import above also fixes the problem that installations, which got zfcp
paths activated by means of rd.zfcp= dracut cmdline arguments, were missing
those paths in the installed system.
Since commit 87ab1ab ("Support cio_ignore functionality for zFCP
devices (#533492)"), /etc/zfcp.conf replaced /tmp/fcpconfig.
Since commit 011ea0a ("Remove linuxrc.s390"), /etc/zfcp.conf only
exists if the user specified dracut cmdline parameter rd.zfcp=.
https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/
handles parsing of rd.zfcp= without /etc/zfcp.conf as of commit
06a30ae529a5 ("zdev/dracut: add rd.zfcp cmdline option handling").
https://src.fedoraproject.org/rpms/s390utils.git
no longer writes /etc/zfcp.conf during deprecated parsing of rd.zfcp=
as of commit
("zfcp: migrate to consolidated persistent device config with zdev")
Hence, nothing populates /etc/zfcp.conf during installer boot anymore.
So python-blivet has no more initial import input to carry forward.

Signed-off-by: Steffen Maier <[email protected]>
Implements the znet part of referenced bugs.

Depends on
ibm-s390-linux/s390-tools@73f51e4
("zdev: add helper to convert from zdev config to rd.znet").
The spec file already reflects the new dependency on `zdev-to-rd.znet` in
the new v2.31.0 of the s390 architecture specific sub-package
s390utils-core.

Dracut commit ("feat(znet): use zdev for consolidated device
configuration"), replaces the distribution-specific persistent
configuration of s390 (channel-attached) network devices with a common
consolidated mechanism using chzdev from s390-tools. So there is no more
ccw.conf nor s390-specific low-level network config in NetworkManager
connections nor ifcfg files.
The spec file update reflects this new dependency on the updated dracut
module "znet" in a new version of the dracut-network sub-package.

Therefore, drop NETTYPE and OPTIONS.

Keep SUBCHANNELS nonetheless because it can still serve as a matching key
for NM connections.

Delegate the generation of rd.znet statements to a helper tool from
s390-tools, which gets its low-level config information from the
consolidated mechanism using chzdev.

There are two different code paths involved:

* Root-fs on something (such as iSCSI or NFS) that depends on znet
  =>_get_dracut_znet_argument_from_connection().
  Related earlier commits:
  commit fa174ab ("Write rd_CCW when root fs is on a network device on s390x (#577193)")
  and lately replacing former code:
  commit f85682f ("network module: add support for getting dracut arguments")
  commit 7cf4d64 ("network module: use network module to get dracut arguments")
  and finally replacing initscripts ifcfg by NetworkManager connection:
  commit 840c984 ("network: generate dracut arguments from connections (#1751189)")
  (Note that this generated rd.znet is independent of the (last) one just
  inherited from the boot parameters between commit 64fb106 ("Preserve
  network args on s390x.") and commit a4ba9ae ("Do not pass rd.znet on
  to installed system unconditionally").)

* Configure znet on boot with rd.znet= but without any corresponding ip=
  and instead use the kickstart command "network" to perform high-level
  configuration of the network interface created with rd.znet. This creates
  a non-initramfs NM connection.
  => pyanaconda.modules.network.initialization.ApplyKickstartTask.run
  => pyanaconda.modules.network.nm_client.add_connection_from_ksdata
  => pyanaconda.modules.network.nm_client.create_connections_from_ksdata
  => get_s390_settings() and _update_wired_connection_with_s390_settings()
  (In contrast, early initrd network setups get both the low-level s390
  config and high-level interface config via nm-initrd-generator,
  which parses rd.znet= as well as ip=.)

Signed-off-by: Steffen Maier <[email protected]>
storaged-project/blivet#1162 (comment)
removes DASDDevice.opts. Anticipating that blivet change, update
the anaconda unit tests making use of DASDDevice.

Signed-off-by: Steffen Maier <[email protected]>
@pep8speaks
Copy link

Hello @rvykydal! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

Line 38:1: E402 module level import not at top of file

@github-actions github-actions bot added the f42 Fedora 42 label Oct 9, 2024
Copy link
Contributor

@M4rtinK M4rtinK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me as far as I can tell & seems like a nice cleanup and simplification. :)

@rvykydal
Copy link
Contributor Author

/kickstart-test --testtype smoke

@rvykydal
Copy link
Contributor Author

Merged in the original #5250

@rvykydal rvykydal closed this Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f42 Fedora 42
Development

Successfully merging this pull request may close these issues.

5 participants