various fixes to get puppet/puppetmaster configurable on redhat #6
Conversation
|
👍 |
Puppet expert required: is this safe? Seems to me like it would depend on puppet's module parse order, and would work iff the apache module is parsed before this module. |
|
It's not using the apache module that I see -- that $apache_service is defined earlier within this init in the case statement at the top |
minor style updates
ghost
assigned 
|
@pkilambi : Looks like this needs rebasing... |
|
sorry for the slow response, I did not realize this was assigned to me. I would prefer that we look at moving to a different module so that we can add redhat support, upgrade to puppet 3.2, and add puppetdb with the same task. I have the following code working with the following modules: , would you consider abandoning these changes and testing out this module? I will go ahead and review the code as well. |
| @@ -8,12 +8,27 @@ | |||
| $mysql_root_password = 'changeMe', | |||
| $mysql_password = 'changeMe') { | |||
|
|
|||
| package { puppet-common: | |||
| case $::osfamily { | |||
There was a problem hiding this comment.
the typical pattern is for these types of platform differences to be separated in a file called module_name::params
There was a problem hiding this comment.
the spacing here looks quite strange, the puppet convention is two space.
It wasn't until this evening, so I'd say no apology is necessary. =) |
|
@bodepd I'm totally ok with moving to upstream module. But i'm not sure if it makes sense for us to do that this late in the release? Perhaps we can merge this fix in for the upcoming release and investigate the new module for the next iteration ? |
|
@pkilambi : Sounds reasonable to me. I'll test this today (thanks for rebasing). @bodepd, any comment on @iawells's question (#6 (comment))? |
|
@iawells - good catch, if ! defined is not a good idea b/c 'notify => Service["puppetmaster"]' wil not be added if the resource comes from somewhere else. Instead, it's probably better to declare the dependency separately: This can result in an issue is the apache service already uses the metaparameter subscribe (this will show up as the error cannot call << on hash, I would not consider this a blocker, just be aware that this change could result in that issue) On a side note, if !defined could be problematic with the other params b/c it can not determine if a resource that was already parsed contains those same params. Perhaps have a look at ensure_resource from stdlib? |
|
|
||
| file { "/etc/cron.d/puppet_cleanup": | ||
| content => template('puppet/puppet_cleanup.erb'), | ||
| require => Package[puppet-common], | ||
| require => Package[$::puppet::params::puppet], |
There was a problem hiding this comment.
I much prefer making references to things based on static titles (only the namevar should be different for resources) both the namevar and title are guaranteed to be unique, and I feel titles are a little more clear.
…snt include these on rhel and is part of yum plugin
|
Ok, that last set of patches seems to have things working on the Ubuntu side again. +1 |
|
Just tested: |
|
So talking to Mark, turns out ubuntu doesnt have a puppetmaster service and only relies on httpd. But on red hat it has both and thats why even though this error happens on ubuntu the services still work as apache is still up. I'll stick in an if check to define this service only on redhat. |
|
This is also why the puppetmaster still comes up and functions on Ubuntu in spite of the error. Essentially it fails to start the puppetmaster service (because there isn't one) but it does deal with Apache appropriately (and that's all that's necessary on Ubuntu since it's configure via sites-enabled and started with Apache itself). |
|
That last patch gave me a clean run. +1 |
|
Likewise. 👍 Clean test run. |
various fixes to get puppet/puppetmaster configurable on redhat
lp bug # https://bugs.launchpad.net/openstack-cisco/+bug/1183555