It might be a good idea to disable iSCSI & Stratis support for now in Anaconda-mode Cockpit storage

[M4rtinK]

When doing some baremetal testing I have noticed that Cockpit storage triggered from Anaconda shows both iSCSI & Stratis options.

The iSCSI option looked functional, but I have not tested it.

The Stratis option was apparently missing some dependencies and showed a concerning error message:

This could be due to the current main environment for the Anaconda WebUI (Live iamge) being an offline installer by default. So it can't download any extra packages & I don't think iSCSI would work without network as well.

Overall I would suggest disabling those options for now, and onnly enabling them again in the future if:

• we have an ack from stakeholders (Workstation WG & Fedora QA) they are supportable (once we start doing Fedora Server images, the situation will be different)
• all options handle lack of network connectivity gracefully (either are not shown at all or user is prompted to enable a suitable network connection
• the options ideally have all requirements available locally or stakeholders are fine with image downloading dependencies at runtime (note - package installation is not possible on the boot.iso, only on Live image)

[M4rtinK]

@mvollmer @garrett @KKoukiou

[garrett]

Yep, agreed.

When in Anaconda mode, Cockpit Storage:

1. should not try to download additional packages
2. should not have iSCSI or Stratus for desktop editions (even when it has support for sever versions in the future, we probably still do not want it on for workstations)

[mvollmer]

Yep, agreed.

When in Anaconda mode, Cockpit Storage:

1. should not try to download additional packages

2. should not have iSCSI or Stratus for desktop editions (even when it has support for sever versions in the future, we probably still do not want it on for workstations)

Yes, makes sense. Let's do that.

[jkonecny12]

AFAIK this will not work in Anaconda mode ever.

The biggest issue is that even if you download the package and install it -> Cockpit will do the formatting. The installed system will miss these packages so it probably won't boot correctly.

I would say, that if any feature in Cockpit Storage needs to download packages, that feature should be disabled in Cockpit. That is a general rule here.

[mvollmer]

2. should not have iSCSI or Stratus _for desktop editions_ (even when it has support for sever versions in the future, we probably still do not want it on for workstations)

Can this be controlled via the packages that are installed when Anaconda runs? I.e., if stratis is available on the D-Bus, should Cockpit still omit it from its menus when in Anaconda mode? If so, does this need to be configurable somehow, so that different editions can behave differently?

If we need configurability, I think I would do that via the existing Anaconda->Cockpit config blob.

[KKoukiou]

@mvollmer I think it's ok to do package detection and show/hide the storage features accordingly in anaconda mode. @jkonecny12 any opinion on this?

[M4rtinK]

I think package detection is a good initial step, but I can imagine other possible variables that could play a role, even if the packages end up on the image (possibly by accident):

• does the given storage tech need network & is network actually enabled ? (Live image does not need network connectivity for installation to local storage, so network might not be operational)
• is it actually possible to boot from a iSCSI volume created from the Live installer & is that tested by CI ?
• does the Workstation WG (and other SIGs once more Live images are supported) want this functionality to be available ?

[jkonecny12]

I don't think we can use feature detection here. The issue is that we are targeting Workstation where user can just install any package of their choice anytime.

[M4rtinK]

I don't think we can use feature detection here. The issue is that we are targeting Workstation where user can just install any package of their choice anytime.

Yeah, that is a good point. Really looks more and more that this should be a fixed per variant/spin policy decision, possibly configured via the Anaconda config file or similar mechanism.

[mvollmer]

Really looks more and more that this should be a fixed per variant/spin policy decision, possibly configured via the Anaconda config file or similar mechanism.

Ok, what do we need to configure exactly?

a) Just online / offline? When offline, Cockpit would omit iscsi, nfs, and clevis.

b) Or the full palette of optional Cockpit storage features? These are currently btrfs, iscsi, lvm2, vdo, (also legacy vdo), clevis, nfs, stratis, and packagekit.

(Currently, packagekit is forced off in Anaconda mode, to prevent installation of on-demand things.)

I'll implement b), since that is the most flexible.

[garrett]

@mvollmer: Yes, don't have any auto-install anything when in Anaconda.

It should only be able to use features already available from installed packages only.

Examples:

• If there's iscsi, nfs, and clevis already on the system (like on a server), then it should be possible to use those.
• If a built ISO doesn't have those (like on a Workstation ISO, for example), then those features that aren't installed already should not be visible.

The problem we're hitting in Anaconda, is that Cockpit Storage shows support for things that aren't installed. The Workstation spin doesn't have those, yet it looks like you can use them and Cockpit attempts to install them and fails. It shouldn't even show them, as they're not installed, and we cannot assume there's a network connection (as there usually isn't even one).

[mvollmer]

@mvollmer: Yes, don't have any auto-install anything when in Anaconda.

Yes, this was done in #20950.

Is there anything else in addition to this that should be done in Cockpit?

For example, we already switch off NFS when in Anaconda mode, regardless of whether support for it is installed or not. Should we also switch off iSCSI regardless of whether it is installed? Or should these two decisions maybe be made according to whether the network is available or not.

[mvollmer]

I'll implement b), since that is the most flexible.

#21150, please comment.

[M4rtinK]

Yes, this was done in #20950.

So if I understand it correctly - package not installed + package installation not possible = feature is not available, right ?

Yeah, I think that should work for Anaconda. :)

Should we also switch off iSCSI regardless of whether it is installed? Or should these two decisions maybe be made according to whether the network is available or not.

Yeah, I think network being up is definitely a pre-condition for using iSCSI. Also I remember that iSCSI might need some special behavior when setup during the installation to be still reliably usable on the installed system - maybe @rvykydal could chime in if it looks like what Cockpit storage provides could be enough for it to work out of the box ?

[martinpitt]

@M4rtinK @KKoukiou is this still an issue? #21150 has been open for some time for anaconda to customize the feature detection, but I don't know the background if #20950 was already sufficient for this?

[KKoukiou]

@martinpitt @M4rtinK @mvollmer @jkonecny12 sorry I have not been following this. I am not very supportive on #21150, as my opinion from the very start of the integration of anaconda with cockpit-storage, is that:

• we are (and should be) treating cockpit-storage as external tool therefore it's possible that it supports more options than anaconda does
• this might be confusing to users, who will be able to create storage layouts in cockpit-storage, which might not be supported by anaconda, but they are able to do it from CLI or..
• users will be able anyway to launch cockpit-storage in Workstation ISO environment from the browser as well, and therefore they is no 'anaconda mode', so they would be seeing all features

@M4rtinK @jkonecny12 have different opinion on this, so we would sync as a team and reply in the PR.

[KKoukiou]

@martinpitt @M4rtinK @mvollmer @jkonecny12 sorry I have not been following this. I am not very supportive on #21150, as my opinion from the very start of the integration of anaconda with cockpit-storage, is that:

* we are (and should be) treating cockpit-storage as external tool therefore it's possible that it supports more options than anaconda does

* this might be confusing to users, who will be able to create storage layouts in cockpit-storage, which might not be supported by anaconda, but they are able to do it from CLI or..

* users will be able anyway to launch cockpit-storage in Workstation ISO environment from the browser as well, and therefore they is no 'anaconda mode', so they would be seeing all features

@M4rtinK @jkonecny12 have different opinion on this, so we would sync as a team and reply in the PR.

The team came to conclusion. @garrett sumarized it at #21150 (comment)

[martinpitt]

Thanks. So given the discussion here and in #21150 , and with the on-demand install already landed, I don't see anything else here. So I take it the status quo is fine now? Please reopen/yell if I missed something. Thanks!