Puppet Community

Thank you for your contributions <@U01AZE7JFPE>! I left some comments on two of the PR, overall makes sense, thanks!

Alright folks that's a wrap, see you next time!

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

:beaker: Next up is _Content and Tooling_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230613T140000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|121 hours>

:kermit_typing: _Content and Tooling_ is about to start up in 15 minutes

Hey guys :wave:, Content and Tooling office hours are starting now! Post any questions/requests you may have here.

Hey <@U01AZE7JFPE>, we don't actually support that module and it is maintained by the @puppetlabs/open-source-stewards group.
Let us see if we can get this moving

If you drop a message into the <#C0W298S9G|> channel one of the members of @puppetlabs/open-source-stewards should be able to get it progressed.

Dropped a message in there, thanks for the pointer

when is a good time to upgrade to `9.0.0`? When all modules in my `Puppetfile` support _(and in some cases *require*)_ `9.0.0`? Any proactive steps in the meantime?

I know there are discussions about rewriting `puppetlabs-firewall` , but this came up recently when I tried to bump `stdlib`  <https://github.com/puppetlabs/puppetlabs-firewall/issues/1137>

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

We have very recently completed a series of dependency adjustments in most of our modules and we are on our way to release them over the coming weeks. I would say the best time to upgrade would be, indeed, when all module in your Puppetfile are Stdlib 9.x compatible (most of them already are, they are just pending official release to the forge).

As for the Firewall issue: last week we merged a PR to ensure compatibility. We hope that PR will address the reported issue. I will add shortly a response to that issue as it seems it flew unnoticed for a bit.

AFAIK, out of all of the modules that I use, `puppetlabs-firewall` is the only stopping me from upgrading to `stdlib` `9.x`.

Sure <@U01AZE7JFPE>, I'll raise this with the team and get it moving

Just released v6.1.0 of puppetlabs-vcsrepo to the forge <@U01AZE7JFPE> :fist_bump:

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

:the_more_you_know: _:fox_face:Vox Pupuli monthly sync; see calendar event for info_ is about to start up in -15 minutes

Our office hour is live in zoom,  join in!

<https://puppet.zoom.us/j/91219793310?pwd=M0pPRklhd0lhL2V6ZldQd1BZRCsvQT09>

And thats the end of Office hours for us this week! We'll be back next week for another session.

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

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

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

Sorry I’m a bit late… \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.

We do want to get more metrics into Orchestrator in general, there are a couple new ones already out in the 2023 releases on the number of plans waiting for resources and running.

What kinds of metrics would be helpful for you? Getting feedback on what people in the wild actually need is super helpful

performance metrics would be helpul. For example: I saw some errors during a long running plan like 'orchestrator/broker could not reach the desired pxp-agents in time' and the plan aborted

PE support suggested that the plan maybe hit too many targets in parallel and we should reduce the concurrency

but that's just a wild guess. Was the orchestrator actually utilizing all assigned cpu cores? how many catalogs/puppet code was it compiling in parallel? how many pxp-agents was it interacting with in parallel/per plan (we usually have multiple plans running)

how much time did the orchestrator spend on each function per plan/target?

we can configure the amount of jruby instances for the orchestrator. Can we check how many of them are used to figure out if we need more/less? Puppetserver has a metric for requested jrubies I think, I'm not sure if the orchestrator already has something similar

and for gaining more performance in the broker I recommend revisiting <https://tickets.puppetlabs.com/projects/ENTERPRISE/issues/ENTERPRISE-1476>

That's great feedback! Thanks!

Having a solid use-case like this is helpful, and this scenario definitely helps define some of the things we could expose and how they help.

We don't have any short-term plans for metrics improvements, because we've been focused on scalability improvements for tasks and plans. However the team is acutely aware that metrics are _very_ lacking in Orchestrator and we do want to improve that and build a more robust story around tracking how Orch is performing

We will push as much as we can for increased priority

<@U02G3CTNEBV> :this: is something we should really keep in mind for medium term planning

if there is anything like a beta in the future that you could make available to selected customers or SDP partners let me know. I am happy to test

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

I do not know, I would raise an issue on the GH tracker for the repository

I meant: are there plans to expose such metrics in orchestrator/classifier

I do know that there is some focus on generally providing better insight into the performance of the various services

I don’t think there are any short term plans for classifier, I can ask about orchestrator