doesn't Puppetlabs want that?

This message was deleted.

They do: https://puppetlabs.github.io/community_management/adoptable_modules.html I'm following the Adopting a "puppetlabs" module process, where we have to fork our own version and put it on the Forge first. Then they review the module, deprecate their version from the Forge, and point to ours

Thanks for the PR feedback, @bastelfreak and ewoud/ekohl! I've updated both PRs with the suggested changes.

Is there a way to configure

.sync.yml

to make a module's`.github/workflows/ci.yml` run litmus instead of beaker acceptance tests? AFAICT, modulesync_config will set up GHA to run beaker tests (

/beaker.yml@v1

) when it sees that a repo has files matching`spec/acceptance/*_spec.rb`—but in puppet-hocon, those files are actually for litmus, so it never runs the litmus tests and every job in the GHA beaker matrix fails.

Is there a way to configure

.sync.yml

to make a module's`.github/workflows/ci.yml` run litmus instead of beaker acceptance tests? AFAICT, modulesync_config will set up GHA to run beaker tests (

/beaker.yml@v1

) when it sees that a repo has files matching`spec/acceptance/*_spec.rb`—but in puppet-hocon, those files are actually for litmus, so it never runs the litmus tests and every job in the GHA beaker matrix fails.

no. we do not support litmus. what you can do is set the ci.yml to unmanaged and write your own

or use beaker :D

I'll need to check how puppetlabs's CI ran the original tests (I don't support Litmus, either 😛)

looking at the elasticsearch and elastic-stack modules that vox has took over from elastic, I'm trying to understand the 'version' parameter in the elasticsearch as it supports true or a number, but as elasticsearch/logstash/kibana are supposed to be the same versions anyway, I don't understand why elastic_stack::version is not the parameter used to control the version

I initially set elastic_stack::version until I realised it wasn't actually doing anything on the elasticsearch module, when I looked it seemed elasticsearch module had it's own version parameter, but it does seem to use the elastic_stack module to actually configure the repo

should I be setting this within elasticsearch or the elastic_stack, is it worth me looking at a change to the elastic module that defaults to elastic_stack version unless overrideen

overridden

I did say you should set both parameters in hiera to the same module

my apologies, where did you say that,

(this is the first time I've mentioned this, are you referencing a doc I've missed)

ups, I just messed up the wording :D

that's ok, my wording was scrappy

as elastic_stack:version is a major version eg: 6,7,8 but elasticsearch:version is a specific version, is it acceptable to set them both to say a major version, and let the package manager dnf/apt just keep bumping the packages within that major version

mhm I dont know how the repo setup works

elastic_stack is pretty dumb it just does $URL/$version

so $version is just the repo major version

however elasticsearch:version you can do 7.13. for example

I 'think' you can just do the major version in elasticsearch:version and that will work as the OS package manager will then just handle what the repo offers

@ghoneycutt I have a co-worker that has run into https://github.com/ghoneycutt/puppet-module-hosts/pull/42 . That module needs some updates. Have you considered transferring it to voxpupuli? If you are willing to consider it, I will commit to updating the module.

@ghoneycutt I have a co-worker that has run into https://github.com/ghoneycutt/puppet-module-hosts/pull/42 . That module needs some updates. Have you considered transferring it to voxpupuli? If you are willing to consider it, I will commit to updating the module.

This message was deleted.

This message was deleted.

RFC: https://github.com/voxpupuli/puppet-systemd/pull/292

I wonder if it doesn't belong in facter itself