Return integers for openldap_database olcSecurity

[gcoxmoz]

Pull Request (PR) description

Storytime!
I was pinned back on a 2.0.0 era module. One directive I had in play was:

openldap::server::database { 'dc=US':
  security => { 'tls' => '1' },
}

I started looking at moving the module forward, and at 3.0.0 I hit

Error: Evaluation Error: Error while evaluating a Resource Statement, Openldap::Server::Database[dc=US]: parameter 'security' entry 'tls' expects an Integer value, got String

I changed the code,

openldap::server::database { 'dc=US':
  security => { 'tls' => 1 },
}

And now every puppet run I started getting:

Notice: /Stage[main]/Profile::Openldap::Database/Openldap::Server::Database[dc=US]/Openldap_database[dc=US]/security: security changed {
  'tls' => '1'
} to {
  'tls' => 1
} (corrective)

I haven't rolled the module all the way forward to see what I'd get, but what I see against module-master that is database.pp's typechecking requires integers as a value for security items (good), and provider openldap_database's security setter is happy to set olcSecurity to be anything (good). But provider openldap_database's security getter is reading the value back out as a string (bad). This leads to the disconnect I'm seeing since writing-1 != reading-'1'.

Most folks who require TLS on their ldap are probably requiring TLS at the server level instead of the database level, so it wouldn't surprise me if people haven't hit this.

"WHERE'S THE TESTS?!"
There aren't any currently, same as when it landed in #157. At that point it was a feature-add which long predated the type enforcements that began in module v3.0.0. I am unclear how I could clone spec/unit/puppet/provider/openldap_overlay/olc_spec.rb to test the read-it-back-out, so I'm submitting sans-tests. Sorry. The .to_i change against module 2.0.0 fixed the "1 vs '1'" issue locally, and the code is effectively unmodified since it landed so it should port forward cleanly.

This Pull Request (PR) fixes the following issues

Reported value of olcSecurity on a database are actually integers, but are being reported back as string-of-integer.

[smortex]

All this makes sense 👍

[smortex]

Nobody complained so I'll merge this. Thanks!