Puppet Community

sounds like it's almost production ready!

So, essentially a local build but wrapped in a container to provide immutability and ease of swapping the OS environment.

But, the offical builds are firmly rooted in VMpooler because they have to consider platforms that aren't Linux contianers: AIX, macOS, Solaris, Windows, etc.

Ah last time, I said I'd post links for future platforms so here's AL 2023 and Debian 12 <https://tickets.puppetlabs.com/browse/PA-5566> <https://tickets.puppetlabs.com/browse/PA-5549> /cc <@U2S1MUUQ7> <@UNNE9882X>

btw, Fedora 36 is dead, Long live Fedora 38

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

oops, little late but will be around for the next hour or so if there are any bolt questions

And Fedora 38 <https://tickets.puppetlabs.com/browse/PA-5512>

:coffee: Next up is _:teacher:Puppet Forge_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230525T180000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|43 hours>

:meeting: _:teacher:Puppet Forge_ is about to start up in 15 minutes

I sense a disturbance in the force. Almost like <@U1PC2RAH0> is going to ask me a hard question.

I had a talk with someone here about md5sum vs sha256 for puppet modules. Are there plans to deprecate the md5 checksums? those aren't available in fips r10k installations

we are actually talking about this right now. I talked to some folks at the OSS summit a couple weeks back about SBOMs and am noodling on whether we can use standard tooling to provide even stronger forms of module signing.

now that pypi went the wrong route and deprecates gpg sigs, it would be nice for the forge to support it

&gt; ways to tag a release as a migration
what would this mean?

like the difference between a major and minor semver release?

so, puppetlabs/community moves a module to voxpupuli

so so not only list in the old module "this was migrated to.." also list in the new module" this was migrated from..."?

exactly, I'd  love to differentiate between a forked migration and voluntary migration

that's something that keeps bubbling up and I think we're going to have to involve some of you in design conversations

like what the most effective and also least surprising experience

for a voluntary migration, I'd just _redirect_ same way that github does for a moved repo

for a forked migration I'd say a ":warning: &lt;Other User&gt; has marked that there may be a newer forked version of this module for community support"

a redirect is tricky when the new owner has a different understanding of semver and a new release in the new namespace breaks your setup

I like that. An authoritative "that is the new version" and an informational only "I made this forked improvement"

I agree, but if it's a migration where both sides are in communication, I feel like the risks are lower

would also be nice if `puppet module list` would list modules as deprecated/migrated

and the people who can add that mark should be like Vox PMC and PuppetLabs Community Managers with some process for the CM to mark a migration between non-Vox entities

that seems easy enough to do. Right now we could add a deprecation marker.

also the right time to advocate for our rake tasks I guess: <https://github.com/voxpupuli/ra10ke>

maybe the whole `puppet module` thing should be deprecated

admin permissions thread at <https://puppetcommunity.slack.com/archives/CFD8Z9A4T/p1685038313765169>

I think that `puppet module` needs to exist because the ability to list modules is a core feature. I'm ok moving advanced features out, kind of how some already moved to the PDK

there's a lot of documentation/howto built around `puppet module install` too

but in reality that's not used in most environments. It's quite slow and most people use code-manager or r10k or librarian-puppet

and the `puppet module build` face was already moved to a dedicated gem

I understand that `puppet module list` is helpful and I also use that often to check if all the dependencies from the different metadata.json files match up, but maybe that's some logic that should be moved to r10k/ra10ke and the face is just a wrapper around it

if we're going that route, should r10k be vendored into puppetserver directly and ra10ke or something like it be merged in to provide a puppet facet for managing r10k?

maybe vendored into puppet, not puppetserver

not a bad idea. Well outside of my decision making though :grin:

it isn't like 90+% of users aren't using r10k

semi related, have I ever shown you this POC? <https://prod.puppet-sneakernet.k8s.puppet.net>

brings up the question again why r10k is kinda deprecated/not activly supported

it seems like an obvious thing to just include as batteries (r10k)

the sneakernet "fork me" link is broken, btw. <https://github.com/puppetlabs/puppet-sneakernet>

<https://prod.puppet-sneakernet.k8s.puppet.net> looks like our new beaker_puppet_helpers, just as a web UI

I'm talking with edwin about potentially integrating it so that becomes a Forge API. No promises on that though.

wrt to r10k, I do believe we're getting more attention on it soon. It's not clear what that attention will be though.

expect for arching the repo, I'm happy with every attention

also given the PE support tickets I created I assume someone will work on r10k

looking more strongly at OIDC too, now that you brought it up a couple weeks back

yes please. take a look at how rubygems does it and try to copy it

this is bleeding over from the other thread :lol:

I would like to do this. It depends on designing some kind of RBAC to grant those permissions

yeah would be nice if there's some sort of RBAC and vox pupuli PMC could approve modules that got migrated to the vox pupuli namespace, but not others (and deprecate modules that got moved to Vox)

personally, I'd also love to have something like a "migration request"

that would send the request via email to the original owner and give them a click to approve migration workflow

that'd be great for the voluntary ones, it's the ones where the owner has dropped off the face of the planet

imho, that would trigger the "informational" notice that you proposed on the other thread. So users would already see a better maintained alternative.

the question then remains of how to manage "forcible" migrations and whether those should even exist.

we had a few situations where Vox Pupuli had to fork a repo. We try to avoid it, but sometimes the owner is just missing  and there's a high demand for the module

another thing: rss feeds for forge accounts, not only for modules

<@U020LK7D0JU> short answer for the feed question. Yes -- we have feeds on the roadmap for modules and authors, etc. We're in a weird state wrt to resourcing right now, so it's hard to estimate a timeline.