New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor to put a knob on all parameters #169
Conversation
…for autoloading from hiera put a handle on all the params of the class in init.pp so that they can be autoloaded from hiera, and easily fed to the class from a profile class
we don't need these defines for this refactor. Removing for simplicity's sake
$ssl = $mysql::ssl, | ||
$ssl_ca = $mysql::ssl_ca, | ||
$ssl_cert = $mysql::ssl_cert, | ||
$ssl_key = $mysql::ssl_key, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This final comma causes Puppet 2.6 to fail. Could you remove the trailing comma on the last parameter?
…n puppet 2.6 Fix to config.pp. Remove trailing , on last parameter, which breaks in puppet 2.6
@@ -11,14 +73,42 @@ | |||
# | |||
# Sample Usage: | |||
# | |||
class mysql ( | |||
$package_name = $mysql::params::client_package_name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing $package_name
as a parameter is the correct thing to do, but will cause it to be backwards incompatible. Could you let the mysql
class continue to accept $package_name
in addition to $client_package_name
and throw a deprecation warning using the warning()
function if someone is using $package_name
?
$package_name = undef,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noting that this is resolved with further commits, but github still shows the comment.
Removal of the ambiguously named package_name parameter, without having a version provide a deprecation warning for a reasonable amount of time seems unreasonable. As Hunner suggests, adding a workaround variable to init.pp and use that as package name gives us the ability to warn users about the upcoming deprecation, while still maintaining backwards compatibility.
…ards compatibility with Puppet2.6
Refactor to put a knob on all parameters
…ve_rhel5_centos5 (IAC-1351) Remove CentOS 5 & RHEL 5 from provision.yaml file
This re-scopes all the variables in the params class to be mysql:: scoped parameters, which default to the values in params.pp. The stock behavior should not change, but one can now (with puppet3 or with a profile class) alter the value of variables which previously would require manual changes to module-owned files.
The intention here is that people will be able to keep up to date with the forge module with greater ease as they will not need to make changes to the module to feed it customizations.