Update init.rb to support Nvidia's Cumulus Linux

[dpkgbofh]

Cumulus Linux uses systemd, not system-v's init.
This fixes errors like:

Failed to call refresh: Could not find init script for 'telegraf'

[puppetlabs-jenkins]

Can one of the admins verify this patch?

[CLAassistant]

All committers have signed the CLA.

[joshcooper]

@dpkgbofh the test failures are unrelated to your PR. Could you rebase your PR on main?

[dpkgbofh]

Hi Josh,
I hope I did this right ... please check.
Cheers, Jan

[joshcooper]

Hi @dpkgbofh Could you rebase your PR onto puppetlabs/main instead of pulling and creating a merge commit in your feature branch? Something like:

$ git reset --hard fa9786d
$ git fetch --all
$ git rebase fa9786d^ --onto puppetlabs/main
$ git push --force origin HEAD

[dpkgbofh]

Hi Josh,

that better?

Please excuse my ignorance!

Cheers, Jan

[joshcooper]

We already set systemd as the default provider in

puppet/lib/puppet/provider/service/systemd.rb

Line 33 in dc0e3ba

defaultfor 'os.name' => :cumuluslinux, 'os.release.major' => %w[3 4]

so curious why we need to "exclude" init? Is the os.name incorrect in the systemd provider?

[dpkgbofh]

This is what is what facter returns on Cumulus:

root@edd-sw30:~# facter -p os.name
Cumulus
root@edd-sw30:~# facter -p os.release.major
12
root@edd-sw30:~# 

The exclusion solution was suggested somewhere on serverfault and is working for me.

[joshcooper]

The exclusion solution was suggested somewhere on serverfault

The pattern we've been following is to specify systemd as the default for a given platform and then exclude older versions in situations where the platform uses init or something else. For example, we do this for debian

puppet/lib/puppet/provider/service/systemd.rb

Lines 27 to 28 in dc0e3ba

	defaultfor 'os.name' => :debian
	notdefaultfor 'os.name' => :debian, 'os.release.major' => %w[5 6 7] # These are using the "debian" method

This way it's future compatible (so long as systemd remains the default) and in theory it helps when documenting which providers are enabled by default on each platform. If we just exclude Cumulus from init, it's not clear what provider is "next" precedence-wise.

I think the root issue is this line is expecting the os.name fact to return cumuluslinux (case-insensitively)

puppet/lib/puppet/provider/service/systemd.rb

Line 33 in dc0e3ba

defaultfor 'os.name' => :cumuluslinux, 'os.release.major' => %w[3 4]

Maybe it did that in previous versions of Cumulus? Or maybe facter 4 is reporting the os.name fact differently on Cumulus? What is the output of facter os? Could you try installing puppet-agent 6 on Cumulus and see what facter os reports?

Related commits

15ed9d1
686d5ca
7ba4df5

[dpkgbofh]

root@edd-sw30:~# puppet --version
7.23.0

root@edd-sw30:~# facter os
{
architecture => "amd64",
distro => {
codename => "cumulus",
description => "Cumulus Linux",
id => "Cumulus-linux",
release => {
full => "12.5",
major => "12",
minor => "5"
}
},
family => "Debian",
hardware => "x86_64",
name => "Cumulus",
release => {
full => "12.5",
major => "12",
minor => "5"
},
selinux => {
enabled => false
}
}

[joshcooper]

Thanks, the root cause is because facter 3 used to report os.name => "CumulusLinux"

So systemd would be selected as the default due to

puppet/lib/puppet/provider/service/systemd.rb

Line 33 in dc0e3ba

defaultfor 'os.name' => :cumuluslinux, 'os.release.major' => %w[3 4]

However, facter 4 reports os.name => "Cumulus", hence this issue. To ensure compatibility with facter 3 and 4, could you add the following to the systemd provider:

defaultfor 'os.name' => :cumulus, 'os.release.major' => %w[5]

I'm assuming cumulus 3 and 4 are EOL?

[dpkgbofh]

Thanks Josh,
agreed!

[joshcooper]

@dpkgbofh I unresolved this based on my comment:

To ensure compatibility with facter 3 and 4, could you add the following to the systemd provider

defaultfor 'os.name' => :cumulus, 'os.release.major' => %w[5]

At which point, I don't think the change to the init provider is needed?