Jira (PUP-10235) Support enable module with dnfmodule package provider

[Jens Almer (JIRA)]

Jens Almer created an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider Issue Type: New Feature Affects Versions: PUP 6.11.0 Assignee: Unassigned Components: Types and Providers Created: 2020/01/14 3:06 PM Environment: CentOS 8, RHEL 8 agents. Priority: Normal Reporter: Jens Almer The dnfmodule package provider currently only supports installing a profile, ala `dnf module install module-name:stream/profile`. Some modules do not provide profiles, and can only be enabled. For example, the 389-ds module. To install, 2 steps are required: `dnf module enable 389-ds:1.4` `dnf install 389-ds-base` I think it would be ideal to allow for an 'enabled' value for the ensure parameter which would change the invocation of dnf. The stream should be passed in with a new or repurposed parameter. A secondary package resource can be used to install the needed package as that is not deterministic. Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Josh Cooper Team: Night's Watch

Add Comment

[Mihai Buzgau (JIRA)]

Mihai Buzgau updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Mihai Buzgau Sprint: PR - Triage

Add Comment

[Mihai Buzgau (Jira)]

Mihai Buzgau updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Mihai Buzgau Sprint: PR NW - Triage 2020-04-01

Add Comment

This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)

[Mihai Buzgau (Jira)]

Mihai Buzgau updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Mihai Buzgau Story Points: 2

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy assigned an issue to Gabriel Nagy

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Gabriel Nagy Assignee: Gabriel Nagy

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy commented on PUP-10235

Re: Support enable module with dnfmodule package provider Hi Jens Almer, I tried to reproduce this case and looks like dnf module install falls back to enable for modules with no default profiles. So apart from the catalog application not being idempotent, what you are asking should be possible with the current code. Can you provide more details as to what exactly is failing? We have a PR open that adds a new parameter which allows a module to be only enabled, but I wonder if maybe I missed something here. Thanks.

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy commented on PUP-10235

Re: Support enable module with dnfmodule package provider

I did some investigation myself, and I found this PR on dnf which changes the behavior of dnf module install: https://github.com/rpm-software-management/dnf/pull/1427/ So it looks like prior to DNF version 4.2.8 you could run dnf module install on a module with no default profile, and it will silently enable it. With more recent versions, the command fails without enabling the stream. Apparently the previous behavior was misleading, since the install command wouldn't install any RPMs (see https://bugzilla.redhat.com/show_bug.cgi?id=1669527). This was a bit tricky to find out since on our test boxes we had an older version of DNF which didn't present this issue/fix.

Add Comment

[Jens Almer (Jira)]

Jens Almer commented on PUP-10235

Re: Support enable module with dnfmodule package provider

Hey Gabriel, I appreciate your work on this! I never noticed the fallback behavior, but I can confirm that is correct. My assumption after observing the lack of idempotency was that it was failing to enable the module. The open PR should meet my needs. Takk! --Jens On Fri, Mar 27, 2020 at 6:28 AM Gabriel Nagy (Jira) <

Add Comment

[Jens Almer (Jira)]

Jens Almer commented on PUP-10235

Re: Support enable module with dnfmodule package provider

I missed your comment about the DNF behavior change. Good find!

Add Comment

[Mihai Buzgau (Jira)]

Mihai Buzgau updated an issue

Puppet / PUP-10235

Support enable module with dnfmodule package provider

Change By: Mihai Buzgau Sprint: NW - 2020-04-01 , NW - 2020-04-15

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Gabriel Nagy Fix Version/s: PUP 6.15.0 Fix Version/s: PUP 5.5.20

Add Comment

[Claire Cadman (Jira)]

Claire Cadman updated an issue

Puppet / PUP-10235 Support enable module with dnfmodule package provider

Change By: Claire Cadman Labels: doc_reviewed

Add Comment

[Vadym Chepkov (Jira)]

Vadym Chepkov commented on PUP-10235

Re: Support enable module with dnfmodule package provider Could you also add an option to disable a module? It's required to use non-modular sources, postgresql 11, for instance

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy commented on PUP-10235

Re: Support enable module with dnfmodule package provider

Vadym Chepkov good suggestion! Should ensure => absent also disable a module? Or should we have a different value for this (i.e. ensure => disabled). I'm also assuming that dnf module disable works on not enabled modules as well? I ran the command against a module not appearing in dnf module list --enabled and I was able to disable it.

Add Comment

[Vadym Chepkov (Jira)]

Vadym Chepkov commented on PUP-10235

Re: Support enable module with dnfmodule package provider

I think `ensure => disabled` is most logical. they marked with letter x in output:   # dnf module list|grep postgresql postgresql           9.6 [x]       client, server [d]                       PostgreSQL server and client module                                          postgresql           10 [d][x]     client, server [d]                       PostgreSQL server and client module                                          postgresql           12 [x]        client, server                           PostgreSQL server and client module

Add Comment

[Vadym Chepkov (Jira)]

Vadym Chepkov commented on PUP-10235

Re: Support enable module with dnfmodule package provider

# dnf module list --disabled Last metadata expiration check: 0:01:36 ago on Mon 13 Apr 2020 05:23:56 PM UTC. CentOS-8 - AppStream Name                              Stream                           Profiles                                 Summary

postgresql                        9.6 [x]                          client, server [d]                       PostgreSQL server and client module                       postgresql                        10 [d][x]                        client, server [d]                       PostgreSQL server and client module                       postgresql                        12 [x]                           client, server                           PostgreSQL server and client module

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy commented on PUP-10235

Re: Support enable module with dnfmodule package provider

Thanks for the additional information, Vadym Chepkov. Would you be able to open a PUP ticket for this functionality?

Add Comment

[Vadym Chepkov (Jira)]

Vadym Chepkov commented on PUP-10235

Re: Support enable module with dnfmodule package provider

sure, https://tickets.puppetlabs.com/browse/PUP-10419

Add Comment

[Claire Cadman (Jira)]

Claire Cadman commented on PUP-10235

Re: Support enable module with dnfmodule package provider

Gabriel Nagy will do!

Add Comment

[Gabriel Nagy (Jira)]

Gabriel Nagy commented on PUP-10235

Re: Support enable module with dnfmodule package provider

For everyone watching this issue, due to the additional use cases of DNF modules compared to other package providers, and because we want to implement a most logical way of managing a DNF module (enabling, disabling, installing, removing, resetting), we are not going to document this feature yet. This means that the current implementation is subject to change, depending on how PUP-10419 is implemented. Thanks for the understanding, and we apologize for any inconvenience this might cause.

Add Comment