Puppet Community

The Forge focus right now is on completely finishing the redesign. I'm sure you've had the jarring experience of dropping back to the old harsh black theme. We're close to getting the entire application ported to the new experience.

it's close, but the last few details are always the ones that take the longest because they're postponed in favor of new feature work

I think that's next on the list. I think I mentioned before that we're going slow on it to make sure that we don't accidentally reveal zero day vulns

it's looking like we might silently block publication with an email or such notification to the author on failures

rather than displaying anything on the Forge itself for a failure

yes I think a new metadata key is great for that

honestly, I'd like to make that available so other companies who commercially support their modules can use it too

would that be something where puppet says it offers support, or maybe something where you indicste the support level like none/silver/gold/ask_bastelfreak or even something where companies would add their support infos

i know at least two companies that probably like to use that

so I hadn't actually thought about support _levels_ much for the badge. But it does actually address some other challenges we're working on

I dont know how Puppet offers (commercial) support for modules, but I think the new attribute should be quite flexible bevause schema updates can be quite painful

I wonder about something like `[Supported: Bronze]` and a new "support" link that would go to a customer support portal linked in the metadata.

the "commercial support" link would have to be quite different from "file a repo issue" and we'd need to put some UX thought into that

and what about the edge case where maybe multiple companies want to offer commercial support. should that be supported?

vox pupuli will probably never offer that for own modules, but maybe betadots/onyx point would like to offer support for vox modules

would bloat up the metadata.json at some point :D

oh that's an interesting idea. What if $random_company wanted to offer commercial support for  Vox modules. Would they have to engage with you to update metadata?

would "Report issues" and "Support portal" links mean different things to you as an end user?

and would "support portal" suggest paid support?

portal always sounds quite expensive, so yes :D

looks loke there are many possible ways this could turn out. I think the goal should be that we define the offered support in a structured way so the forge can index it and male it searchable for end users

thats why I do not want any random badge in a readme or consulting companies listing in on their website

I'm also just a little nervous about making it easy for terrible support leaches promising support for other people's modules

you could have an allow/deny list on the forge add add those people/companies to the deny list

maybe what we do is make a section on the Forge where companies could list their services and surface that in a generic sidebar. So it doesn't seem like Vox is endorsing any specific company, unless you specifically added it to your metadata

thanks for the ideas. Will noodle on them a bit

Much belated, sorry.  My current struggle is that, between forge and github and jira, there’s a chance for a disconnect on what a module’s state is.  Like, currently, the absence of a ‘Supported’ label is meaning “we decided it’s not supported,” but that is indistinguishable from “we missed making a decision.”  So I’d suggest that non-supported module have a complete ‘retirement’ checklist, ala a final commit updating the README + r/o archiving + explicit ‘unsupported’ (bikeshed that for marketing-approval) label on forge + updates to any properly tagged jira issues.  When there’s only parts of that, there’s room for doubt.

I would like to know if they are actually dead before forking some of them. and actually I prefer to not fork them

the big ones you're concerned about will be unarchived soon. The others, I'm working on a plan for ownership so that's more clear. See this for more information <https://puppet.com/blog/the-evolution-of-puppet-community/>

hah, yeah, there's no way that module is going away

oh, and shortly, I'm actually going to deploy a Relay workflow to audit modules and identify live modules pointing to archived repos.

undecided whether that will just report or whether it will auto-deprecate. Will have to see how many show up :grin:

if you want community to help oit with those tasks I would happily help out

either is fine tbh. `FORGE` is where they'll end up to be acted on, but sometimes the `MODULES` team needs to weigh in on them

I think I'd say, file it to `FORGE` and if they need input, they can tag in the modules team as needed. I'll move that one now.

the longer version, the forge team will do the work and if it's effectively just moving a module to a new namespace they won't need extra input to approve something that's already approved

but if it's a _new_ approve request, then the modules team has to evaluate it

but you don't really have to care much about that because they can ask for that eval on their own

wtf atlassian. In the middle of moving the ticket it just randomly redirected me to <https://www.atlassian.com>

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

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

\o Good day y’all - console office hour has begun!

If you have any questions/suggestions for anything related to the console, any of the console services (RBAC, Classifier, Activity Service) or the Orchestrator, ask away.

I have a PE setup and people from other teams need to lookup hiera data. usually we do that with puppet lookup on the cli, but we do not want to give them root access. do you have any ideas how to properly implement this?

I considered a task with rbac, which does the puppet lookup

I dont think normal shell users can authenticate with rbac and be allowed to do puppet lookup?

I am quite good at coming up with interesting problems

I do not think there is an API call that ca do lookups? only the CLI?

Yeah a task that runs `puppet lookup` as a command is probably the best way. You could use the `lookup` function, but you would need to do it within an `apply` block with the appropriate facts defined, which is pretty heavyweight

:meeting: Next up is _:teacher: Bolt_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20220510T140000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|112 hours>

OK, that’s a wrap for today - we’ll be back in a couple of weeks. Y’all be good to yourselves!

Please help... :slightly_smiling_face: Why can't I have an exec resource that restart the same service (_systemctl restart nagios-nrpe-server_) in more than one class/place? If I had 10.0000 ansible scripts I could easily do the same thing in every  one - hassle-free. I want to restart because of one config file changes here, another one there....

We have another class that makes sure the service is running. But in another class I wanted to drop another NRPE definition file into it proper place and then restart. Can I notify a service resource written in another module/class?

What I typically do is create a class for the configs and one for the service and chain them in `init.pp` : `Class['nagios::config'] ~&gt; Class['nagios::service']`

Any changes to nagios::config will restart the service. The service class is a simple resource declaration stating the service should be running and enabled.

yes you can reference resources from other classes/modules

ah, I missed that part of the question. Thanks bastelfreak.

What would the synatx be for referingto another class resource defined like:
class skolv_nrpe.... {
  exec { 'reload_nrpe':
    ....
   }
}
Something like this....?
class another_class {
  file { $op5_nrpe_cfg:
        ensure =&gt; file,
         ...
        *notify =&gt; Exec[ skolv_nrpe::exec['reload_nrpe'] ]*,
   }
}

all resources have a unique name. so `Exec['reload_nrpe']` is your way to go

Is it that simple? :slightly_smiling_face:

By George it worked! That was really simpler than I imagined! Thanks a lot both of you!
"_Reloading nagios-nrpe-server configuration (via systemctl): nagios-nrpe-server.service"_

The general idea in puppet is to describe the dependency chain and tell puppet what you want so it does everything you want in an order that eliminates repeated service restarts.  But you can notify a service or almost anything to tell it that to happen after this resource 

What would the synatx be for referingto another class resource defined like:
class skolv_nrpe.... {
exec { 'reload_nrpe':
   ....
}
Something like this....?
file { $op5_nrpe_cfg:
      ensure =&gt; file,
       ...
      notify =&gt; Exec[ skolv_nrpe::exec[reload_nrpe'] ],
    }