Puppet Community

what would you think of a checkbox like
&gt; :white_check_mark: Hide low-quality content

one of the things we're discussing is how drastic the cleanup should be
1. deprioritize with search ranking
2. hide with checkbox
3. deprecate with advance notice to author
4. just delete it

obviously, the heuristic for "low quality content" is going to matter a lot too

I know some people use modules long after they should…. maybe hiding is better.  OR!!! you could archive them in some way like we did with the old docs.

even if we deleted (with notice) the author could republish to get it back.

Maybe getting them out of the “project/module”, “1.2.3" for mat from the Puppetfile, and forcing them to get moved down to a git resource instead.  That would cement in the customer’s mind the module is going to be struggling a bit.  That way if the author abandons or the module gets removed altogether, they had plenty of warning.

The wording look "aggressive", but the feature would be great. That mean the concerned module would have a corresponding "marking" in search results and in the module page. Something that basically screams "GO AWAY"

I also want the QA tab to surface the denmark project smells

is looking into that project, never heard of it before I think

<@U11HA7VJ7> I haven’t been read in.  What’ all this smelly denmark thing?

back in a moment, the roof has no power outlets and my battery is nearly dead

Something that tell end-users the reason this choice may not be ideal and maintainer hints to make their module better is great I think.

I've been thinking about this for a while

the only "solution" I can think of is a massive massive test matrix

but stdlib is important enough that perhaps its worth it--if only for that module

The one thing I’m squinting hard at is puppetlabs-stdlib gets upgraded and nukes a function that is front-and-center in puppetlabs-postgres

See the `puppetlabs-stdlib` module at <https://forge.puppet.com/puppetlabs/stdlib?src=slack&amp;channel=office-hours>

running the test suite of all Supported modules against a candidate stdlib release would be huge, but maybe worth it.

do you think that would be representative of "all modules on the Forge"?

I’d be happy with Puppet supported modules.

I surfaced the issue using the PuppetDB module

If I didn’t know how to configure PuppetDB manually, I would’ve been stuck

well, I'll put in a ticket to consider the mega test suite

Didn’t y’all use to have some monstrous Jenkins already?

a number of my things broke with the latest uplifts that have been going around

Actually, I think I'd like to loop in <@UDDJQQZ38> and <@U01MXBB09RC> to the conversation. It would end up being on them to understand the problem and then evaluate how we should resolve it. They're both in EU timezones and may not get to this for a bit.

Sounds good. Discussing the best solution with the right guys is way better than rushing out.

one thing that I have to admit is that I don't quite understand is what a dnf module IS and how it's different from packages.

They are like splitting the repository in groups of packages to manage some funcionality. Installing a module installs all packages needed to fully provide that functionality.

In that sense, it's almost the same as good old group-install, but it has 2 new and quite nice features: streams and profiles

what parts of it don't fit the "package" model?

Streams are somewhat like "branches" in your repository for one module. They can have, for example, different versions of the package group.
You have to enable one, and only one, stream. Then, dnf does all stuff from packages in the specific stream. That also handle dependencies - all packages of a stream are compatible.

Profiles are subsets of the module for a specific funcionality. Like server, client, development, and the like. You install the profiles for your use, and it's all set.

right, but aside from names, is there a reason that using `package` to ensure that a module was present or absent, etc. doesn't work?

<@U11HA7VJ7> I understand the difference is how it groups packages, dependencies and versions. In the package model, you install a single package, and it comes with the dependencies for it. In the module model, you install all packages needed for the solution. Also, choosing versions in the package model gets tricky if you need to install many packages - like having to enable multiple repos.

like, does it need an entirely different set of parameters?

See the limitations I listed in the opening message. They can probably be solved in core `package` type, but it gets increasingly messy.

I see that. Point #2 could be resolved with better documentation

point #1 is kind of arbitrary where we want to draw the line

Currently, it hacks the `package` type parameter names to DNF module streams and profiles. But I feel it gets more and more hacky.

yeah. To me, if there is not a clean mapping then it makes sense to make a new thing.

but I don't see a compelling reason to say that dnf _modules_ can't/shouldn't be managed with the package type

in any case, someone who knows better than I can wade in. :grin:

<@U11HA7VJ7> My main reason for that is that a module is not a package.
Likewise, a package could be managed by `file` and `exec` types. But it is a package, so let's go with `package` type.

sure, but to be pedantic, neither is a freebsd port and you could even argue that a chocolatey package isn't really a package, it's normally just a wrapped installer.

Puppet does abstractions and if a thing is _package-like_ and represents "install this thing to put software on a system" then it fits the mental model of a package

I completely see that the advanced dnf feature don't fit that model

That seems like a reason for a type the package resource supports and then a module that manages and configures dnf itself

and again, I'm totally willing to be convinced that a dnf module is sufficiently not package-like to fit that mental model, but just saying that it's not the same isn't quite enough.

<@U11HA7VJ7> Gotcha. Well, that's the reason I brought the question here: I'm not sure either. I'm glad more people are crushing brains to get this answered.

I do think I like <@U11JXDFJ9>'s idea. I don't know enough about it to know if it's feasible or not

<@U11JXDFJ9> Do you mean a separate module, or resource, to manage the streams, and `package` resource to do the install/remove part?

So, yum has a couple functions out there.  Puppet natively supports yum repo packages…the type is assumed on the platform (correct me if I’m wrong <@U11HA7VJ7> )

Package understands dnfmodule because it’s whole goal is putting $thing on $node.

There is another forge module that configures yum itself.  Yum.conf, etc.  seems like a similar breakout could manage some of that complexity better.

<@U11JXDFJ9> Yes, one of the solutions (my preferred one, indeed) is to use Forge module yum for such configuration. That's because my personal understanding is managing repos and streams should not be a task for `package`. Plus, doing so while also installing profiles, IMHO, is quite confusing to the developer.

are repos/profiles/streams/etc effectively _configuration_ for DNF?

A proposal:
• Implement stream management inside yum module
• Patch `package` so it doesn't mess with streams (like it does today)
• Patch `package` to accept none, one or multiple profiles

<@U11HA7VJ7> Repos and streams, for sure. Profiles, I've mixed feelings.

Alternative:
• Patch `package` to accept any stream spec - None, current, default, specific, maybe latest (hic sunt dracones)
• Patch `package` to accept none, one or multiple profiles
• Fully document the beast

wait. Using the dnf provider with package will _change_ the streams configuration? That seems.... non-optimal

For what it's worth, I'm a random user who was surprised that DNF modules were managed as packages within the package resource. Once I understood that, I found I could work with it, but it was still not what I expected.

I had sort of expected something more like:
```package { 'foo':
    ensure =&gt; 'present',
    provider =&gt; 'dnfmodule',
    module_name =&gt; 'foomodule', # made-up parameter
}```
...and then puppet would automatically do whatever is necessary behind the scenes to install the 'foo' package (and dependencies?) from the 'foomodule' module.

I don't know if something like that would really be better, though. DNF modules are strange beasts and it might be best to be explicit about what gets enabled.

<@U03ULG4CKKK> You hit one of the confusing aspects: should `package` resource with `dnfmodule` provider manage a module profile, or a package from that?
It can be answered, but the other use will be missing. Plus, what a mess!

can `module_name =&gt; 'foomodule'` be represented on the command line for the `dnf` binary?

if so, then you can do that with `install_options` (not ideal)

To my thinking, enabling a DNF module doesn't install any software--it only enables installing software. Thus, it isn't really a package or something that works like "package". The current behavior seems shoehorned.

...but it does work, so I'm not really complaining.

when you "install" a module with dnf it doesn't install anything? It just makes them available to be installed?

(clearly I don't use dnf and I'm now super confused, haha)

Those are good questions. I'm not very good with modules (haven't used them much yet) and need to look at documentation.

If someone finds useful, <https://dnf.readthedocs.io/en/latest/modularity.html|here are the docs>

Untitled

I skimmed the modularity page a bit ago, but I think that a lot of my questions are deeper than what it covers.

In short:
• A DNF module has all packages, for all streams and providers. We don't (un)install it - it's just there
• A stream is a version within the module. We configure DNF to use a specific stream (or none) from a module.
• A profile is a subset of packages from the module which enable a functionality. We (un)install one or more of them to get a ready solution.

&gt; can module_name =&gt; 'foomodule' be represented on the command line for the dnf binary?
Not that I know of. My understanding is that installing something from 'foomodule' entails:
1. Enabling the module.
2. Using a normal 'dnf install' to install the specified package (or to install a different package which _depends_ on something from the module).

&gt; when you "install" a module with dnf it doesn't install anything? It just makes them available to be installed?
That is correct as far as I know.

I'll definitely defer to somebody else who knows this more, though, if I stand to be corrected on any of the above.

The module setup seems like a decent idea in general, but yes, confusing, and possibly fraught with peril (e.g. if a module provides updated versions of packages in use and those updates are not desired).

So, when we do, for example:
`dnf module enable &lt;Module&gt;:&lt;Stream&gt;`
We tell DNF that, everytime we deal with that module, its profiles, or individual packages, we want packages from that stream.
Or, if:
`dnf module disable &lt;Module&gt;`
DNF should use no stream, what equals saying everything from that module is unavailable

so in a broad sense, a dnf module is a bit like enabling the puppetlabs repository so that you can then yum install puppetserver

OTOH, when we do:
```dnf module (un)install &lt;Module&gt;/&lt;Profile&gt; [ &lt;Module&gt;/&lt;Profile&gt; ... ]```
We tell DNF to (un)install all packages that (en|dis)able the functionality provided by the profile(s)

but it's namespaced so there's not the global name collision problem

if that's reasonably accurate, then I'm in favor of not overloading the package type

<@U11HA7VJ7> Kinda like that. I'll chase a more concrete example.

Seems like <@U3XLGRAEM>’s dnf example up there shows that Module and Profile can be extracted to a “this configures DNF” module and the basic functionality resides with the package type.

For the purposes of brevity and similarity, I wish the provider was “dnf” and not “dnfmodule”, but that’s my OCD talking

<@U11HA7VJ7> Ah, just no for the namespace part. Modules aggregate packages, but any package can be a part of as many modules as it needs. There's no collision, because packages have unique names.
The aggregation is more for convenience - You want a mysql client? Install module/profile mysql/client, and done. No worries about which packages are needed.

&gt; For the purposes of brevity and similarity, I wish the provider was “dnf” and not “dnfmodule”, but that’s my OCD talking
The "dnf" provider installs regular packages, like the "yum" provier (dnf is the successor to yum).

The "dnfmodule" provider enables/disables modules, which is a separate operation.

<@U11JXDFJ9> About the provider, I guess "dnf" would be confusing too - "yum" provider calls dnf when applicable, as people would expect. It'd not be clear we're talking about DNF modules.

I guess I should have been saying "module stream" instead of "module", since the streams are the level of granularity. The concept is the same, though--enabling a module stream provides the ability to install the set of packages in that stream.

based on the way you've described it, I think it's perfectly reasonable to use `package` with yum/dnf to install packages and to create another module with for modules/profiles/streams/etc

<@U03ULG4CKKK> Exactly. Plus the profiles thing.

All: a new module to manage DNF module streams, or a new resource in Forge yum module? This 2nd idea is from the fact that dnf is a yum replacement, people use them interchangeably (to an extent), and the settings the Forge yum module does apply to both.

The dnfmodule provider source is impressively small.
<https://github.com/puppetlabs/puppet/blob/main/lib/puppet/provider/package/dnfmodule.rb>
That's probably an indication why it was implemented as a package provider. Despite the end-user results being un-package-like, the set of operations is very similar to a package.

<@U3XLGRAEM> technicalities aside, does one generally consider dnf to be more or less the same as yum but better? If so, then it makes sense to use the `yum` module as it will help people migrate to the new tools over time.

Yes. Except for new features like modules, dnf syntax and config files are exactly the same. In general, people use yum when they don't know dnf exists or are just too used to type "yum".

&gt; All: a new module to manage DNF module streams, or a new resource in Forge yum module?
Whichever way you do it, I think it should be available as part of core puppet packaging. I don't know how this works, but for example, cron_core is a separate module, right, but as a puppet user I don't need to specifically get that module, since it's shipped with puppet. I think. I'm murky on the details here.

<@U03ULG4CKKK> Just saw the provider. Indeed small and simple, just to make the `package` resource to support choosing a stream and installing a profile. OTOH, doesn't fully support DNF modules features.

If you need more features, that it does probably make increasing sense to not have it be implemented as a `package` provider.

Maybe the fact there's a `dnfmodule` provider in `package` resource makes it a better choice to implement in Puppet core, rather than in a separate module, like yum.
Thoughts?

My reasoning earlier is that DNF modules are a core feature of RHEL, and since RHEL and derivatives are widely used, managing DNF modules should be a built-in feature of puppet, or at least distributed in a way to seem as if the feature is built-in. Beyond that, I don't really know.

Remember, though, that the provider k owns about the package the dnf subsystem is responsible for installing and that’s it.  Even with Yum or Apt you need a secondary module to actually configure the OS service.

Just for correctness: dnfmodule provider knows the module, not its packages

Just to mention: I played a whole lot with writing a type and a provider to manage DNF module streams and profiles. So, whatever path we end up finding the best, I'm comfortable with jumping into the code.

I would agree with the assesment here that it sounds like management of streams and modules should be in the yum module as similar to repo management <@U01MXBB09RC> what do you think? Whatever we do a follow up blog article would be good to highlight it to users

<@UDDJQQZ38> Would that be configuring the streams in yum module, then (un)installing profiles in core `package` type with `dnfmodule` provider? Or both in yum module?

<@U3XLGRAEM> my gut would say installing and uninstalling in package ideally

<@UDDJQQZ38> What do you think about wrapping all up in this roadmap below?
• Implement stream management in yum module
• Patch package type to accept none, one or multiple profiles
• Deprecate stream management in package type
• Thoroughly explain everything in docs
    ◦ Including the part that package type with dnfmodule provider (un)installs *profiles*, not packages

sorry for my delay here but yes that would sound like a plan <@U01MXBB09RC> do you agree ?

<@U058WNATUCU> note we will need to see where this can be planned into priorities with <@U01MXBB09RC> but just to copy you in for awareness of these discussions

<@U1QVBAUS2> In case you'd like to check our reasonings before further PR review

Thanks for the ping. I am in meeting hell most of today but I will try to respond today.

:kermit_typing: Next up is _:teacher:PE Console_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230727T210000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|2 hours>

my $2c wrt the search results in Forge.. I’d prefer ranking algorithm which sorts according to some scoring.. better modules goes up, older goes down. That should be good enough from my point of view.

those should have wide enough puppet reqs then :thinking_face: unmaintained modules doesn’t have it usually

if module wants EOLed Puppet version.. well.. someone should fork it and update the requirements

at least it’s not hidden in the output so you still can find it (e.g. if it’s the only module for something)

Things like motd, resolv_conf, etc.  some have been around for years and years and due to their simplicity almost never get touched, but still work just fine.  That’s the kind of things I’m thinking of.

oh for sure. But due to the way that modules &amp; the forge work currently, they still need someone to at least run the tests and update the metadata

<@U11HA7VJ7> like rubygems does it, I would like to see a reverse dependency tree in modules

:letsplay: _:teacher:PE Console_ is about to start up in 15 minutes

Got waylaid by a bug but am here now and will be here for the next hour or so. If you have any questions about the PE console, or any of the services that feed into it, fire away!

anything we can be excited about in the september release?

I showed this the other day, I think it’s gonna make some folks happy: