It would be good for openQA tests to check that various aspects of handling modules across release upgrades work correctly. I don't think we have a formal list of those requirements, but at least some of them are:
If a module is enabled with the default stream, and the definition of 'default' is different between the 'from' and 'to' releases, the module should be correctly switched to the new default in the upgrade
If a module is enabled with an explicitly-specified stream, it should stay on that stream after the upgrade. If that stream is not available for the new release this should be reported as an error that prevents the upgrade, but --allowerasing should allow it to proceed (and disable the module?)
--allowerasing
@sgallagh @langdon anything to add to that?
Metadata Update from @adamwill: - Issue assigned to lruzicka - Issue tagged with: newtest
I'd rephrase the first bullet slightly. What we mean there is that if a user has picked up a package because it was part of a default stream of a module and has enabled that stream implicitly, then on upgrade they should transition seamlessly to the default stream on the new release.
If, however, they have ever indicated a preference for the stream (even if it happens to be the same as the default stream), such as doing dnf module enable modulename:modulestream or dnf install modulename:modulestream, then DNF should treat that as a conscious decision and follow the behavior described in bullet two. Also, there will be a feature offered to allow the user to "unset" the explicitly chosen stream, if they want to resume tracking the default stream for any reason.
dnf module enable modulename:modulestream
dnf install modulename:modulestream
Regarding bullet 2, I think I'd refrain from attempting to describe how it should work with --allowerasing just yet; we need to have a conversation with UX experts to figure that out first.
I will keep an eye on this. There is a Modularity test day coming in near future, so I will make sure, we have a test case developed that explicitly requires that behaviour. Also, I will review and update the test cases we already have to go more with use case base approach to cover what people might require from modularity.
I don't think any of the current openQA tests / test cases cover a distro upgrade, do they?
No, they do not. But the current test cases need a revision, too.
I am currently working on a little different approach to modularity testing and when I have it ready, I will modify the openqa tests to work accordingly.
Just a quick update .... currently, modularity upgrades are not fully working. I will revisit this before branching F32 and see what the situation will be about the modular upgrades.
This was finished a long time ago and modularity tests were running for the specific versions of Fedora. Since then, Modularity has been dropped, as well as the Modularity tests.
Metadata Update from @lruzicka: - Custom field story_points adjusted to 2
Metadata Update from @lruzicka: - Custom field story_points adjusted to 1 (was: 2)
Metadata Update from @lruzicka: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.