Puppet Community

but all this is really... not great. I suggest sticking with graphite

and graphite allows you to use <https://forge.puppet.com/modules/puppetlabs/puppet_operational_dashboards/readme|https://forge.puppet.com/modules/puppetlabs/puppet_operational_dashboards/readme>

While ago I had an idea to try this: <https://docs.victoriametrics.com/#graphite-api-usage>.. though still had no chance to try

My experience with jmx reporter wasn’t great.

<@UH6N2JZBP>: I'm using <https://github.com/eiiches/scriptable-jmx-exporter> 1.0.0-alpha3 with no issues. It was a bit of a pain to build the YAML config for the exporter, but definitely doable.

I can share upon request.

puppet server version is 7.9.3. Java is OpenJDK 11.0.17.

image.png

<@UNNE9882X>: If you are already invested in VictoriaMetrics/prometheus _(which is my case)_, the _new_ JMX exporter made perfect sense for me.

Pretty sure, I used <https://www.puppet.com/docs/puppet/7/server/sample-puppetserver-metrics-dashboard.json> as the starting point for grafana dashboard.

I had something going, but the performance was horrendous when I tried to scrape extra metrics I wanted. It was a little while ago, so can't remember the details too well.

Maybe I was also after some function metrics???

or per environment metrics??  Can't quite remember.  But the rules available in the exporter (which was the official JMX reporter), either meant I didn't get what I wanted, or I got _way_ too much and scraping took several seconds.

Maybe the scriptable JMX reporter solves that.

i do have a graphite environment and the reason i need something with prometheus is because we want to transition away from graphite. but i can standing up a small graphite cluster to keep stuff like this working: because it’s working pretty well. i just thought there was a nice endpoint that prometheus could connect to to collect the same metrics. i might look into the jmx exporter as well. i know that victoria metrics can accept graphite traffic as well but i’m not using it now. 

There's also this <https://github.com/puppetlabs/puppet_operational_dashboards>

<@U01RH6J4QDC> I’d ask you to share the jmx exporter config pls

<@UNNE9882X>: <https://github.com/eiiches/scriptable-jmx-exporter/pull/32>

Here is `curl` output in README.md :slightly_smiling_face: <https://github.com/eiiches/scriptable-jmx-exporter/pull/32/files#diff-7a273fca6db73a683b104a6bca9e4b75f4c7ebd18869af95584b4820eab5591dR50>
I’d recommend to redo with `curl -s`

TY, force pushed new commit to pull request.

<@U01RH6J4QDC>, is my understanding correct that this should run on the puppetserver machine? What’s the exact command line to invoke the agent there? It seems that one of the arguments is a path to the target class

oh i think i get it, `-javaagent` needs to be added to the command line for starting puppetserver

Here's mine:
```-javaagent:/opt/prometheus/scriptable-jmx-exporter-1.0.0-alpha3.jar=@/opt/prometheus/scriptable-jmx-exporter.yaml```

<https://github.com/voxpupuli/rspec-puppet-facts|https://github.com/voxpupuli/rspec-puppet-facts> also this

<@UNNE9882X> yeah if you raised an issue that would be great please.

or
```$ alias pe
alias pe='pdk bundle exec --'```


Alias requires change in your shell. What I’d like to have is aliases defined in the current module repo (like in .git/config)

understood, but this way you don't have to wait for someone else to do it. :slightly_smiling_face:

Yes, but I like to make this world a bit better place (did no ticket still though) :)

Raised it here: <https://github.com/puppetlabs/pdk/discussions/1206> <@UDDJQQZ38> FYI

It’d be nice to have either 1) `pdk rake` alias for `pdk bundle exec rake` or 2) ability to create pdk aliases and/or commands per directory or repository (like in `git`).. otherwise it’s hard to write `pdk bundle exec rake &lt;something&gt;` for every task.. I guess I should raise a ticket for this.

hi all, I have a `bash script` and I call it with `Exec resource type` in puppet. the `script.sh` have `exit 1` in it and puppet dont like that I get below error:

`Error: /Exec[run script.sh]/returns: change from 'notrun' to ['0'] failed: 'script.sh' returned 1 instead of one of [0] (corrective)`  

I can change the exit 1 to exit 0 but its not so nice  solution or in command attribute for exec set like this:

 `command =&gt; 'script.sh; Exit 0',`

Is there a better way to solve this? thank you all

generally 0 means success to unix scripts

wow the attribute is nice :slightly_smiling_face: Ill test it <https://www.puppet.com/docs/puppet/7/types/exec.html#exec-attribute-returns> thank you <@U11R8J59S>

<@UDDJQQZ38> yes you are right, when I call the script.sh from CLI it should return exit 1 on failur but when puppet run the script.sh and the script return 1 puppet throw the error.

your answer helped me already <@U11R8J59S> returns =&gt; 1, but I want that the user who run it localy or via puppet that he see an error... so if I set the attribute returns =&gt; 1, the user will not see the error!

I gave you 2 answers, you chose the wrong one :slightly_smiling_face:

no I just test that with returns its good to know what the attribute also do, so I test it.
Im already change the script :slightly_smiling_face:

<@U11R8J59S> thank you, it works like I want but I change my script.sh :slightly_smiling_face:

you can add the the digit_algorithem in puppet.conf: <https://www.puppet.com/docs/puppet/7/configuration.html#digest-algorithm>

I am guessing that this can also be a install param?

if you want set it in cli its like bewlo... with install I think you can set it but Im not sure:

`puppet config set digest_algorithm sha256`

maybe its best to upgrade to Puppet 7 and leave the filebucket set to the old md5 algorithm and then once all the infrastructure and agents are upgraded, you swap the digest algorithm over to the new one?

if you upgrade puppet to 7 the sha256 is default. so your filebucket will not work.

That mean you have to set this entry in puppet.conf for all agents and for server on puppet 5/6

then upgrade to 7 in this case you are safe...

ah but what if I set the puppet server to use md5, upgrade all the agents to 7, then fix up filebucket to use sha256?

If your server use version 5/6 it’s already default md5

If you upgrade all agents to 7 you have to change the default for your server to sha256 so in this case both will have sha256. 

You can already  add that entry via puppet in puppet.conf for all agents. 

Do you have only Linux agents ? 

typically I upgrade my puppet server, and then get the new agents from there (PE).

but this bit is different due to filebucket algos changing

That doesn’t matter I’m just asking because I have also a plan to upgrade all windows to puppet 7… do you want use puppet for that ? 

I was originally going to update Filebucket first. but I thought maybe I can do it the other way around? but maybe its better to do filebucket first.

The easiest way it’s add via puppet the digest_algorithm to puppet.conf for all agents and change it on the server. Restart server… 

That’s all 

If you install puppet 7 on agents the default is for them sha256 and on server is still md5… 

That’s why it’s better to change it for all 

yeah but I have to upgrade the master first.

its PE and all my agents pull the installer from the master

Wow that’s cool, we use open source version…

So you don’t need to write any classes to upgrade them ? 

nope. just using the `puppet_agent` module from the forge and have the repo's do all the work for Linux. Windows is similar, it just pulls the msi down from the master and performs an in place upgrade

Ah really? Same for windows ? It will upgrade it ? 

For puppet agent upgrade on Linux and windows:

<https://forge.puppet.com/modules/puppetlabs/puppet_agent/readme|https://forge.puppet.com/modules/puppetlabs/puppet_agent/readme>

the other option I have thought about was just disabling file bucket, upgrade to 7 straight and then re-enable filebucket.

possibly the most straight forward option

Of course you can do that too. In worst case you will lose one file ( if one is md5 and other sha256) 

yeah. we haven't had to use filebucket much so right now we are ok with that

Hi , I am trying to upgrade Jenkins  , we have configured Jenkins using puppet , some how i am able to see failing is it related to puppet code configuration 

what exactly is the problem? figuring out if puppet is managing jenkins?

you can check the puppet log and check if it did anything on the system

or run `puppet agent -t` on the cli and check if it does something

you can also check cachedir to see what classes and resources it's applying on a run.

in case puppet succeeds but you don't get what you want.

Puppet succeeds I can see the page . But see error in logs 

couldn't tell you about jenkins itself. if puppet isn't erroring, then puppet is doing what you told it to do successfully and likely whatever you told it to do is not quite right :grimacing:

it does look like projectMatrix (a plugin?) can't auth, maybe a missing dependency on a plugin. But that's a total wild guess on my part.

But not applying all the plugins installation 

it's been years since I ran Jenkins but my biggest problem was that the plugin list just installs what you tell it to and doesn't pick up dependencies.

yeah. this doesnt look like a puppet problem

just a wrong jenkins config and/or missing plugins

That looks like it is for ERB, not EPP. In EPP that would just be $sensitive::mysecret

Since epp is puppet language any bare word like scope is a string. 

I'll try it now. Documentation foobar? I can see if there's a place to submit a PR

Looking up via scope is how you get to puppet variables in Ruby.

Docs error, yes- please file a ticket with Puppet’s Jira for DOCS.

Will do. Should secrets automatically be available under the $sensitive scope? It's coming back empty in my template output

The thing `sensitive::mysecret` is just an example for accessing something in a user defined class named `sensitive`  and getting its parameter `mysecret`. There is no feature in puppet that makes all secrets available in some scope.  What you do is simply reference the variables that hold values, and some of them may have a `Sensitive` value.

ooooohhhh ... that makes sense. Thank you!

We are seeing the same issue in our automated testing pipelines.

Yeah, `concurrent-ruby` 1.2.0 removed a private class that Puppet was depending on. Pinning to `concurrent-ruby ~&gt;1.0, &lt; 1.2.0` is probably the best solution at the moment.

<@U11MDJNGZ> Is that something we can do on our own?  If so, what's the best way to do that?  (We don't control the docker image.)

<@UTZFQKAEM> if your CI does the bundle, just add this line to your `Gemfile`:

```gem 'concurrent-ruby', '&lt; 1.2.0'```

Ooh, timely!
Is there a public ticket I can track progress/updates on this, to know when we can un-pin? Many thanks.

Does this affect puppet, too, in some way? Thus far it's only been puppetlabs-spec-helper for us (CI tests).

<@UEE8BSDC4> given the AIO package bundle Ruby and the needed gems, that should not be an issue.

<@UEE8BSDC4> I saw no ticket so opened <https://tickets.puppetlabs.com/browse/PUP-11722>

just hit us, from the jira ticket

Workaround:

Add this line to the Gemfile to use the previous version of concurrent-ruby :

gem 'concurrent-ruby', '&lt; 1.2.0'

The sticking point will be Java support for UNIX domain sockets. I think first-party support only landed in a recent Java release. pgJDBC may or may not support it.

Most Puppet installations use TLS encrypted connections to address the security aspect while allowing the PuppetDB and Postgres services to run on separate nodes --- which is needed to run the service at scale.

Looks like pgJDBC can use UNIX sockets:

<https://jdbc.postgresql.org/documentation/use/#unix-sockets>

But, PuppetDB doesn't include the optional `junixsocket-core` dependency that is required. So, UNIX sockets are not supported by PuppetDB.

Enabling TLS when connecting to the database works just fine though --- that's the configuration that Puppet Enterprise uses.

thanks for the implementation details. I will take this info and see what we can do!

hey folks, anyone using a socket for the communication between the puppet server and puppetdb? Our security folks would like us to do so. Code like this <https://github.com/puppetlabs/puppetdb/blob/7.x/docker/puppetdb/docker-entrypoint.d/10-wait-for-hosts.sh#L74>
makes me wonder how far out of support this would be

hey folks, anyone using a socket for the communication between the postgres and puppetdb? Our security folks would like us to do so. Code like this <https://github.com/puppetlabs/puppetdb/blob/7.x/docker/puppetdb/docker-entrypoint.d/10-wait-for-hosts.sh#L74>
makes me wonder how far out of support this would be

It depends on how you declare the variables you're passing to epp()

yep.  both ways work. I recommend passing them explicitly

I thought I had worked on something that used plain `module::variable` but I'm actually using `&lt;%= lookup(module::variable) %&gt;` to get it out of hiera.

but you have to declare them in the header of the template

Okay I'm not declaring them in the header (yet), I thought that was optional.

The docs indicate, "You should use class variables when a template is closely tied to the class that uses it, you don’t expect it to be used anywhere else, and you need to use a _lot_ of variables." ... I'm hitting those criteria, and figured it wasn't necessary to write them out in the header

general rule is to avoid such toplevel variables

if thats not possible, you can disable puppet-lint for specific lines

<http://puppet-lint.com/controlcomments/|http://puppet-lint.com/controlcomments/>

So what's the best way to declare a variable which I want to expose to multiple classes?

(I will need to head out in a few minutes)

I have multiple classes which refer to the same url

I'd like to use the same variable for all classes so I change it in one place

alternative: put the logic into a class, reference the class variable from other classes (but hiera is way cleaner)

So in Common something like
global::my_url

each class that needs it should have a parameter. the url gets set in my_url

and in hiera you map all the class parameters to my_url

Thanks. Seems a bit of a rookie question in hindsight

<https://puppetcommunity.slack.com/archives/C0W298S9G/p1670963758094899|https://puppetcommunity.slack.com/archives/C0W298S9G/p1670963758094899>

There's still a lot of consideration going on about how to modernize things. One of the things I feel Puppet got caught out with is in reality how poor big Enterprises are at using Kubernetes / Containers in general which probably stalled this in general

I guess. But it is Puppet's fault for not being a proper steward of the tech with its own ecosystem.  Containers should have been the go to way to deploy puppet. Not some clunky OS heavy model of splattering bits and tools everywhere.  I still love and use it, because the competitors have faultier models, but puppet just hasn't considered more grandiose models of moving to where the community wants to be.

<@UDDJQQZ38> I am not sure if I fully agree. yes kubernetes adoption in enterprises is slow (and I think that is good). But rancher/docker/nomad is common for the PE/FOSS Puppet customers we support. I never saw good and maintained docs for the puppet containers so I guess there is a chicken and egg problem here. camptocamp is the only company I know with a big containerized setup and they started with it before Puppet provided images

Development of a solid strategy for the future that includes public cloud and containers was/is the issue. Enterprises are looking to vendors to help them make the difficult things easier. This requires the appropriate investment from the vendor to help the customer succeed.

cd4pe and comply are on replicated and can deploy in customer kubernetes and I think we had expected PE to follow but to be blunt most large organisations are lacking the people and knowledge to operationally run kubernetes based applications at all.

It's therefore been a huge amount of support effort compared to traditional deployments. I'm not saying Puppet doesn't have to work towards a cloud native / containerized solution but I don't think people are aware how big the gap still is, which is complicating how to find the right balance.

When PDK was looking at being replaced with PCT and other components and developers wanted to make it container based it became clear very few enterprise customers would actually be able to use it.

maybe start with FOSS users and see how stuff gets adopted? That is usually easier/faster

I agree and to be honest once the new roadmap settles in I would be surprised if we didn't look that way in the near future

Agree <@UK7D48A3U> - So I recently migrated to running puppet on nomad clusters, which has been awesome.  But it was not turn key.  Puppet should be creating the ecosystem where the software can easily be consumed and run in any fashion simplifying adoption.   Puppet solves a different problem in a different way than ansible, but it has done a disservice to growing the community in recent years on declarative system management (where I think it actually leads the way).  I don't know if it started in the Clojure migration, ruby getting a bad community rep,  or any other 1 single event, but it has been a culmination of these type of things, the latest with docker containers being removed and thrown in an archive toy repo.   I tend to think if the community was strong, it would bleed into the enterprise and services from puppet being purchased thereby raising all ships.  This latest move is definitely not a positive direction, regardless of how or where puppet wants to go. Its the wrong one.

<@UDQ5RNQJD> to be entirely honest there has been a painful clean-up period, a number of projects were started without realistic owners in Puppet who could ensure they were maintained properly. As was seen with much of the module cleanups.

If for example, we had kept those docker containers in the Puppet group that would have given the impression we were maintaining them. When in reality we haven't been doing anything with them for some time. So it doesn't actually change anything with them other than we are hopefully being more honest about where they actually are and what you can expect for them in terms of maintenance and development.

On the other side of this, there should be a new roadmap out shortly, and from a product standpoint we are strongly trying to represent that past choices, which led to enterprise-only / exclusive type developments were a mistake and as you say what comes from the community does raise all ships.

So it is frustrating things like the docker implementation just aren't there, but it is among many things we will want to work with the community to drive into the product properly.