Puppet Community

nice: <https://github.com/mmckinst/puppet-lint-legacy_facts-check/blob/master/lib/puppet-lint/plugins/legacy_facts.rb#L29-L98>

So Essentially I install this linter on my local dev box and run the cmdline to have it automatically search through the manifests and replace legacy facts.... that is nice!   Top Scope facts was going to be another one and that gave me a link to that linter...Thank you!

You will have to setup CI to deploy environments to the new server eventually, right?  can you go ahead and set that up now?

Yes, but I want for CI to work with the old environment while i’m testing.  Can my `master` branch be associated with puppet6 server and `puppet7` branch with puppet7 server?

do you only deploy a single environment to your servers?  I was thinking that you would have all the environments on both servers.  Even if `production` on the puppet7 server is your puppet6 production environment, you can still run the puppet7 environment on clients

Hmm, i’m okay with running my environments on both servers, but how do i configure it…?

I didn’t know it was possible.  Didn’t even consider it.

r10k can deploy multiple puppet environments based on git branches.  I guess you aren't using that functionality?

I haven't worked with r10k in a bit, and there are some new features, so I'm not sure the best way to do this now is

`r10k deploy display -p --detail puppet7` is not providing me any information regarding master/server.

<https://github.com/puppetlabs/r10k/blob/main/doc/dynamic-environments.mkd>

okay, but where would I specify that `puppet7` environment must be associated with puppet7 server..?

Otherwise, the changes will still be done on puppet6 server, which is useless in my case.

I have multiple environments.  `master` stays for now on <http://puppet6.domain.com|puppet6.domain.com>.  `puppet7` is now should be associated with <http://puppet7.domain.com|puppet7.domain.com>.

the answer of how to use the puppet7 environment on clients is in your original question.  use `--server <http://puppet7.domain.com|puppet7.domain.com> --environment puppet7`  on agents to test that environment.  I am imagining that you would have the `master` environment and `puppet7` on both servers

Yes, i understand.  But if i want to make changes to the `puppet7` environment, how do i do with git/CI? The changes will be done to `puppet7` environment on <http://puppet6.domain.edu|puppet6.domain.edu>, which is is not what i want.

there is a chance I am totally confused and not fully following you :slightly_smiling_face:

```[[runners]]
  name = "<http://puppet6.domain.com|puppet6.domain.com>
  url = "<https://versions.domain.com/>"
  token = "blah"
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]```

that’s my gitlab-runner configuration, so it’s specifying <http://puppet6.domain.com|puppet6.domain.com>.  Can there be a runner for <http://puppet6.domain.com|puppet6.domain.com> as well?

that was what I was suggesting in my first response.  You will need to deploy environments to the puppet7 server eventually, and very likely you will want to deploy to both simultaneously as part of the migration.  Go ahead and figure that out now; then you will have the environments on both servers, and use git to manage changes

I would expect you could add another runner that targets your puppet7 server, but I'm not sure what that config is for

Well, figuring out how is the problem :slightly_smiling_face: I understand what i have now and what i want to accomplish.  It’s “how” that’s confuses me….

Hello All,

I would like to get notifications whenever a new version for puppetserver or puppet releases also if any new vulnerability is there for existing version including the remediation

Can someone please suggest me how I can achieve it ?

IIRC there was an RSS feed for vulnerabilities at least..

use voxpupuli-puppet-lint-plugins to cleanup your codebase. also I recommend unit tests

Thanks that lint plugin set looks useful and covers some of the ones we don't have yet. I've just setup our CI to test with 8 as well as 7 for future changes but those might help focus the mind a bit. We have a smattering of unit tests so that's on the list too but they are quite fragile.

ensuring that you're running on the latest versions of modules is also recommended

:slightly_smiling_face: Yeah that's a never ending exercise! I assume that a lot of them won't be tested against 8 yet either.

we're working on it :slightly_smiling_face:

:slightly_smiling_face: That was not a criticism just that's 8 is still pretty new.

yeah all good. Didn't take it as criticism

there's also a new stdlib release. that might cause some trouble for you as well

And tbh the voxpupuli ones tend to be pretty painless for upgrades etc.

Ooo yeah "remove all the things!" :slightly_smiling_face:

yea, don't do stdlib 9 yet, give that a little time to settle :slightly_smiling_face:

<@U1PC2RAH0> a potentially dumb question.  To use voxpupuli-puppet-lint-plugins, do i use the same puppet-lint command…?

so puppet-lint is quite stupid/doesn't do much. it's extended by plugins

now you might ask yourself, which plugins should I use

Yes asking myself :slightly_smiling_face: I’m using bunch of them, but don’t know best practice

voxpupuli-puppet-lint-plugins is a meta gem from the puppet community that pulls in all current plugins

<https://rubygems.org/gems/voxpupuli-puppet-lint-plugins> you can see that here

Yes i installed it, but not sure if it’s actually using it

so as long as you use that gem, you don't need to worry about the puppet-lint plugins to use, the community does that for you

I do, but i know my co-workers do not.  I have puppet-lint in my setup and also as part of CI/CD

Is there a way to see which puppet-lint plugins are being actively used in my own current setup? again, i apologize for a dumb question

latest pdk already ships voxpupuli-puppet-lint-plugins, so running `pdk validate puppet` should use that and you don't need to do anything

that depends a bit on how you invoke puppet-lint

I just do `bundle exec puppet-lint site-modules`

as part of my .<http://gitlab.ci|gitlab.ci>.yml

I also added puppet-lint to pre-commit… I hope my co-workers are using it, but it’s not up to me.

maybe i should add `pdk validate puppet` to .gitlab.ci.yml?

you can run `bundle exec puppet-lint --list-checks` to see all plugins/checks that your puppet-lint knows

if that's a pdk compatible module I recommend using `pdk validate` instead of invoking puppet-lint directly

so should i remove all other puppet-lint related gems and just leave puppet-lint-plugins one?

```$ gem list |grep puppet-lint
puppet-lint (4.0.0, 3.4.0)
puppet-lint-absolute_classname-check (4.0.0)
puppet-lint-anchor-check (2.0.0)
puppet-lint-file_ensure-check (2.0.0)
puppet-lint-leading_zero-check (2.0.0)
puppet-lint-lookup_in_parameter-check (2.0.0)
puppet-lint-manifest_whitespace-check (0.3.0)
puppet-lint-optional_default-check (2.0.0)
puppet-lint-param-docs (2.0.0)
puppet-lint-param-types (2.0.0)
puppet-lint-params_empty_string-check (2.0.0)
puppet-lint-resource_reference_syntax (2.0.0)
puppet-lint-strict_indent-check (3.0.0, 2.1.0)
puppet-lint-topscope-variable-check (2.0.0)
puppet-lint-trailing_comma-check (2.0.0)
puppet-lint-unquoted_string-check (3.0.0)
puppet-lint-variable_contains_upcase (2.0.0)
puppet-lint-version_comparison-check (2.0.0)
voxpupuli-puppet-lint-plugins (5.0.0)```

I think all of them are pulled in by voxpupuli-puppet-lint-plugins, thats fine

i’ve had most of them before the installation

I am not a huge pdk fan, but if it is a pdk style module, use pdk

pdk is usually installed as an rpm/deb package

okay, i’ll play around with adding it to my CI/CD process.  Thank you again!

Hello :slightly_smiling_face: do we have any specific date for release of puppet on bookworm ? Debian's puppet has different setup than official's

would u mind to tell me/send me link of lira issues? Im just user of ur product is I do now know if Iam authorised to see that. Is it public or private ?

<https://tickets.puppetlabs.com/browse/PA-4995>

Check that pe-modules version 2023.3.0.0 is installed, and not 2021.7.5.0

I’ve seen that when it’s still using puppet_enterprise manifests that have legacy facts in them, and we only removed them in 2023 AFAIK

I think I've got it fixed, about to rerun the upgrade installer. I removed a the pe.conf which hadn't been changed since this PE was installed in 2018, and had a bunch of values explicitly listed that were defaults. puppet made a bunrch of good config changes once I removed that old pe.conf

yeah upgrade to 2023.3.0 done. I didn't install this PE originally, so that pe.conf interference was unexpected, I thought everything was configured in the console or hiera.
now I get to try migrating this primary server from Ubuntu 18.04 to 22.04.
thank goodness for VM snapshots, sure makes things easy (as long as you remember to take snapshots before making changes!)

would have been nice if database_ini.pp used a data type that allowed string and explicitly converted to a number, like it does with some other parameters in there

that second error just looks like a bug in the PE puppet code

making a support ticket, the Product Version selection box doesn't even list 2023.3.0 :unamused:

well, reverting to my pre-upgrade snapshot, removing the bad data in the console, running puppet on the primary, and running the upgrade installer again gives the same error. so not sure how to fix this.

used `puppet lookup` to see that the string port value is coming from `/etc/puppetlabs/enterprise/conf.d/pe.conf`

just did an in-place upgrade of my PE 2023.5.0 primary server (serving about 2000 nodes) from Ubuntu 18.04 to 20.04 to 22.04 :muscle:

Hello Folks, Trying to upgrade from Oracle Linux7&amp;Puppetv6   over to   RHEL9 + puppetv7. Wondering if someone could share their performance tuning journey here.

Currently,
The baseline for Catalog Request Mean Duration is between 3secs - 4secs (Oracle Linux 7 and puppetv6)

To reach this baseline on Oracle Linux 7 and puppet V6 it takes up to 6hrs of time.

Semi-random comment... unless you have a specific reason to go to 7, I'd go to 8 at this point.  7 will be reaching EOL around midyear (some overlap support until beginning of next year).  You might want to just get yourself as fully current as possible.

Is it wise to go from 6 directly to 8? Can you just skip 7 altogether without repercussions?

With proper testing, yes. There are a few potentially breaking changes in 8, all of which can be caught by PDK validation.

I’m doing this right now, and can verify  <@UPVF2CKRP> ‘s statements.  PDK has been essential.

Folks, Any suggestions around the JMX settings and max_active_threads and other JAVA -XX: settings ?

All the above suggestions around skiping version7 is noted, but currently do not want to focus on fixing the puppet code

Also it would help if you can share your baseline performance for catalog compilation mean duration.

I understand this depends on many factors like your code base + memory available + jmx min/max + active threads + load avg + cpu usage, etc.  Still trying to have a dialog around how are you all doing the performance baseline and what are your variables, how many CPU cores does the baremetal have ? or how many VCPU's have you assigned to your POD in Kubernetes

<https://www.puppet.com/docs/puppet/8/system_requirements#hardware_requirements>

<https://www.puppet.com/docs/puppet/8/server/tuning_guide.html>

<https://www.puppet.com/docs/puppet/8/server/configuration>

set the channel topic: Upgrade Documentation: <https://help.puppet.com/osp/current/Content/PuppetCore/upgrade.htm>