specific version for icinga2-*

[matthiasritter]

Hi,
is there a reason why a specific version of icinga2 isn't implementet (yet)? Currently it is set to "installed".
If using puppet to install and configure icinga2 on more then only a few systems (in our case 3000+), there is a need to set a specific or at least "latest" as version-parameter.
What are your thoughts about this?
Thanks

[Reamer]

I'am against "latest", but we should make it configurable. Default should be "installed" or "present".

[matthiasritter]

yeah, I agree with you

[bobapple]

Building the version string is nearly impossible during to differences for each operating system.

Lets say we add a parameter version. The users expectation is to fill in a valid Icinga 2 version number like 2.6.2. However, the package resource requires a full package name to install a specific version. Building the correct package name only out of this version number is hard. Let's see the differences between each OS:

• Debian 7: icinga2-common_2.6.2-1~debmon70+1_all.deb
• Debian 8: icinga2-common_2.6.2-1~debmon8+1_all.deb
  • Mind the difference between debmon70 and debmon8. No idea where this is coming from.
• RHEL 7: icinga2-2.6.2-1.el7.centos.x86_64.rpm
• RHEL 6: icinga2-2.6.2-1.el6.x86_64.rpm
  • Missing centos string. Why?!
• Ubuntu 14.04: icinga2-bin_2.6.2-1~ppa1~trusty1_amd64.deb
• Ubuntu 16.04: icinga2-bin_2.6.2-1~ppa1~xenial1_amd64.deb
  • Hooray, unified package names!

These are just some examples to demonstrate the problem. I have also seen other differences in the past. We would need a "version handler" to somehow create the correct string needed. I don't think this should be added.

Another option is to add an ensure_package parameter that defaults to installed and which can be overwritten with a string. The user would need to enter the whole package name by himself. Adding fixed package names will probably break more stuff than it will do good, but for someone this may work.

Another problem to consider is that not all versions are always available on packages.icinga.com. Old versions are removed at some point and the module will fail. Not even fixed package names would fix this.

[Reamer]

I think the main reason of @Matze85 for make the version configurable is to keep all icinga2 agents up to date.
Maybe we can add a "Warning" for change the version to a specific value. How users solve your described problem to place the right version on a specific operatingsystem shouldn't the problem of this module.

[lbetz]

Reamer is completely right. Puppet as an config management tool shouldn't perform tasks of a software management.

[matthiasritter]

@Reamer Yes that's the main reason. If the version is not parameterizable in this module it's worthless for us.

[Sukiyakijango]

i dont see the harm in making it parameterizable... there a quite a few people using puppet to control versions accros theier infrastructure... as an example we use it to control our puppet(server) version...
or mariadb version.. till i began using this module i even controlled the icinga2 versions... including schema migration... diffrent os diffrent hiera files...

[lbetz]

@Sukiyakijango this works?

[Reamer]

It can work, if you have a hiera hierarchy like this one

• %{::osfamily}/%{::operatingsystem}/%{::operatingsystemrelease}

Best Regards
Reamer

[Sukiyakijango]

like promised we do something like
`$dbversion = regsubst($::icinga2_wrapper_module::version, '^(\d+).(\d+).(.*)$', '\1.\2.0')
exec { "schema-upgrade-to-version-${dbversion}":
command => "/bin/mysql -u root -p'${root_db_pass}' ${db_name} < /usr/share/icinga2-ido-mysql/schema/upgrade/${dbversion}.sql",
user => root,
subscribe => Package['icinga2-ido-mysql'],
refreshonly => true,
}

`

[lbetz]

How this will work if you update two or more versions?

The icinga project do that in different files and so we get problems. The solution to put schema updates in the module itself raises the complexity and maintenance effort of the module. At the moment I think it's a good idea the have an option manage_package to disable the handling of any packages and you can do everything you want outside in a wrapper (profile) class.

[Sukiyakijango]

it was never my idea to put this in the puppet-icinga2 module...
my idea is if you accept the pull request to this issue...
the folks out there can work a way to do theier updates or fix a version via theier roles and profiles...
we do continus updates so the code snipet works for us great...

[bobapple]

Would the issue be solved if we use ensure_packages from stdlib?

Users who want to set a specific package name or installation options could do so by using ensure_packages themself. We had a similar discussion in #28

[lbetz]

Noop, the function ensure_packages works only if you are using the same attributes AND values.
That mean, using
ensure_packages('icinga2', { ensure => installed })

inside the module and outside a declaration like
package { 'icinga2':
ensure => latest,
}

will raise an error.

[lbetz]

With #250 I think we can implement one parameter 'ensure_package' for using inside the package resources of icinga2 and the ido feature classes. Then we need also a trigger to the service if we updated the package. With #250 we'll be protected from an aborted restart when a ido schema update is needed.