@Robert Waffen Huh, interesting.. wonder why im running into a

Error: Could not install module 'herculesteam-augeasproviders_sysctl' (v2.6.2)\n  Dependency 'herculesteam-augeasproviders_core' (v3.1.0) would overwrite /etc/puppetlabs/code/environments/production/modules/augeasproviders_core\n    Currently, 'puppet-augeasproviders_core' (v3.2.0) is installed to that directory\n

Only difference is im using core 3.1.0 afaik. Will need to investigate further

See the

herculesteam-augeasproviders_sysctl

module at https://forge.puppet.com/herculesteam/augeasproviders_sysctl?src=slack&channel=voxpupuli

@Robert Waffen Huh, interesting.. wonder why im running into a

Error: Could not install module 'herculesteam-augeasproviders_sysctl' (v2.6.2)\n  Dependency 'herculesteam-augeasproviders_core' (v3.1.0) would overwrite /etc/puppetlabs/code/environments/production/modules/augeasproviders_core\n    Currently, 'puppet-augeasproviders_core' (v3.2.0) is installed to that directory\n

Only difference is im using core 3.1.0 afaik. Will need to investigate further

https://github.com/voxpupuli/puppet-augeasproviders_sysctl/pull/65 should we just merge & release it, even though there's an idempotency bug on Puppet 7?

I don't use the module myself so I don't have time to investigate why it fails, but that is in acceptance testing so it's likely going to show up in production environments too

uhm, assumed there is some degree of expected failures based on this issue at core https://github.com/voxpupuli/puppet-augeasproviders_core/issues/41

uhm, assumed there is some degree of expected failures based on this issue at core https://github.com/voxpupuli/puppet-augeasproviders_core/issues/41

Most of it looks like WIP, so maybe its just a matter of time

This message was deleted.

@Lukas Audzevicius maybe this is some dependency f*ck up. because sysctl depends on core and core on sysctl. or it is the problem, when you switch the version in Puppetfile from one vendor to another, but the name stays the same it will be confused. in most cases I deleted the old module first and then install the new on. thonk

This message was deleted.

and the modules are compatible, just not all augeas modules are eleased yet in our namespace

ewoud: or drop puppet 7 for mow and make a release?

bastelfreak: I suggested that earlier in the PR and inclined to move forward with taht

ewoud: sounds good to me

bastelfreak: still, little time on my side and since I'm not a user, it's low on the prio list

I might be able to take a look later

ewoud: https://github.com/voxpupuli/plumbing/pull/259/files a short one. do you mind taking a look?

can I get a review for https://github.com/voxpupuli/modulesync/pull/261

arghh... This modulesync build is driving me crazy.

I thought I had it passing, then reverted a small debug change to

ruby-git

and everything is failing again.

can I get another review, for https://github.com/voxpupuli/beaker-docker/pull/91 ?

has anybody an idea how to validate json as data type? so class requires to get a valid json sting as input

why would you want that?

I'd suggest to use real variables and then serialize to JSON if needed, or accept a String and attempt to parse that, but I don't think data types are really suited for inspecting strings

if that's a config file: many tools, like nginx for example, support config file validation. we use that in the puppet modules and don't need to care too much about strict datatypes

Jup, would be to allow handing a custom config file content... validating as json would be minimum for me

of yes, the file resource type has a validate command and you could use that

sounds like a good plan.. ty

https://github.com/voxpupuli/puppet-nginx/blob/master/manifests/service.pp that's an implementation with the exec resource