storage: Allow Anaconda to override feature detection #21150
Conversation
mvollmer
force-pushed
the
storage-anaconda-feature-config
branch
2 times, most recently
from
f0ea950 to
09c0e1a
Compare
|
@M4rtinK, would this be what Anaconda needs? |
mvollmer
force-pushed
the
storage-anaconda-feature-config
branch
from
09c0e1a to
94addba
Compare
|
I think this is still valuable to us. |
Alright! I get this into shape. |
mvollmer
force-pushed
the
storage-anaconda-feature-config
branch
2 times, most recently
from
b6a6f65 to
102d69f
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
mvollmer
force-pushed
the
storage-anaconda-feature-config
branch
from
102d69f to
5552b5b
Compare
|
This was being discussed on Anaconda Slack again. I'm writing my thoughts (same as I've mentioned before) here too: If something is available on the system, then show it. If that feature is not available on the system, do not show it. We should determine whether a feature would be shown by default based on how the ISO is built, which basically means whether a package is included or not on a build, and Cockpit would check if the feature is available at a feature-level. (Live workstation ISOs will have different packages from server ISOs, and the two will have different features exposed based on the capability of the system due to the packages installed.) There should be nothing special about Anaconda, except maybe things are built or configured in such a way as to never offer installation from within Cockpit. (This doesn't have to be Anaconda-specific.) If someone installs something on a live system before opening Cockpit Storage in Anaconda, they'll see it. If they know how to install something, they probably know how to use it, and that's that. They have "their own shotgun for their own foot" (so to speak) and can deal with the ramifications of having a more complicated UI than intended. We need to make sure things are correct by default. We can't ever cover every case, like "What if someone does XYZ in the terminal while the system is running?" People already can do all sorts of wacky self-sabotaging things when they have a command line on a Workstation ISO, and I think this is no different. Summary:
|
|
Thanks @garrett This also matches my gut feeling -- I don't see the necessity to provide a config system for this. PR #20950 should already disable the on-demand install in Anaconda mode (point 2). So is there still actually something to change? @KKoukiou @jkonecny12 as you previously mentioned your support/request for this PR, has this changed in yesterday's discussion, or did the summary miss something? Thanks! |
mvollmer
force-pushed
the
storage-anaconda-feature-config
branch
from
5552b5b to
7eaa3b2
Compare
|
I think the summary has its point. No more objections from my side. If we find this is requested in the future we can start the discussion again. However, so far I think this is the best option. |
| } catch (error) { | ||
| console.warn("Can't enable storaged btrfs module", error.toString()); |
There was a problem hiding this comment.
These 2 added lines are not executed by any test.
| } catch (error) { | ||
| console.warn("Can't enable storaged iscsi module", error.toString()); |
There was a problem hiding this comment.
These 2 added lines are not executed by any test.
| } catch (error) { | ||
| console.warn("Can't enable storaged lvm2 module", error.toString()); |
There was a problem hiding this comment.
These 2 added lines are not executed by any test.
| if (!client.anaconda_feature("vdo")) { | ||
| client.features.lvm_create_vdo = false; | ||
| return Promise.resolve(); |
There was a problem hiding this comment.
These 3 added lines are not executed by any test.
| if (!client.anaconda_feature("legacy-vdo")) { | ||
| client.features.legacy_vdo = false; | ||
| return Promise.resolve(); |
There was a problem hiding this comment.
These 3 added lines are not executed by any test.
|
Ok, let's archive this. |
See #20844.