-
Notifications
You must be signed in to change notification settings - Fork 268
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
Only create config_dir in specific cases. #210
Conversation
e8a345c
to
4aae7d9
Compare
# $config_dir should only be created if default value is used and the OS | ||
# is Gentoo or if a custom value is used | ||
if $config_dir { | ||
if $config_dir == $haproxy::config_dir and $::osfamily == 'Gentoo' { |
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.
Shouldn't this comparison be if $config_dir == $haproxy::params::config_dir ...
? The value of $config_dir
in this manifest is passed down from haproxy
(init.pp), through haproxy::instance
. The values of $config_dir
and $haproxy::config_dir
will always be the same, no?
In addition to @antaflos' comments on the code, I'd also ask which other module has authority on touching haproxy's config_dir, and whether it would be better to fix THAT, instead of burdening haproxy with conditionals. |
D~ Dependency cycle was detected with the ‘zleslie/pkgng’, ‘0.2.5’ package:Error: Could not apply complete catalog: Found 1 dependency cycle: (Exec[pkg update] => Class[Pkgng] => Package[haproxy] => Haproxy::Install[haproxy] => Haproxy::Config[haproxy] => File[/usr/local/etc] => File[/usr/local/etc/pkg.conf] => Exec[pkg update])M From: David Schmitt [mailto:notifications@github.com] In addition to @antafloshttps://github.com/antaflos' comments on the code, I'd also ask which other module has authority on touching haproxy's config_dir, and whether it would be better to fix THAT, instead of burdening haproxy with conditionals. — |
This is indeed a messy situation, with no clear solution. One could point blame to the overzealous Haproxy::Install -> Haproxy::Config dependency and extract the File[$config_dir] into a separate class that is outside of this dependency. Long-term this would suit itself very well to a freebsd-base module. Short-term special-casing it to $osfamily == 'freebsd' might be a easier solution to contain this here. |
the problem really seems to be that there are only two scenarios where the $config_dir needs to be created:
this isn't a freeebsd-specific problem. in every OS except gentoo, the default $config_dir already exists, so as @DavidS says above, the haproxy module is overzelaous in managing this resource since there should be no need to do so if the default is used. if the defeault $config_dir was created during installation in gentoo, we could just say: if $config_dir != $haproxy::params::config_dir {
file { $config_dir:
ensure => directory,
owner => 'root',
group => 'root',
mode => '0755',
} but @pmlee wrote it this way so he didn't screw over the gentoo users. for completeness sake, the underlying issue is that pkgng manages the file resource /usr/local/etc/pkg.conf. and since haproxy started managing /usr/local/etc, the haproxy file resource began auto-requiring the pkgng file resource, creating the dependency loop. |
Would it not be simplier to just create a boolean property called something like "manage_conf_directory" and let the user decide? Thanks |
Hi @pmlee, Any updates on this PR? |
@sethlyons @pmlee Some very valid points were brought up regarding the directory management issues in this define. I believe if we were to continue with this patch, the update made by @antaflos needs to be implemented. Also, another way to make future maintenance of this conditional easier would be to do the check upfront and assign it to a new variable. Like this:
Then in the lines you changed it can merely say:
I feel like this would make maintenance simpler if we were ever to have to change the conditions for config dir management down the road. Definitely up for discussion though. |
@pmlee I was just wondering if you had had a chance to look at this? I think this would be very beneficial to the users of this module! Thanks! |
4aae7d9
to
c5e2c4e
Compare
what do you think of this new commit? i believe it should address everyone's concerns. |
$custom_fragment = undef, | ||
$config_dir = $haproxy::params::config_dir, | ||
$config_file = $haproxy::params::config_file, | ||
$manage_config_dir = $haproxy::params::manage_config_dir |
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.
missing a comma at the end of line here
I like it, except for the syntax error. |
c5e2c4e
to
41f5e15
Compare
updated. |
Only create config_dir in specific cases.
8adbf88 began managing the $config_dir, but that is only necessary if the default value isn't used or if the default is used AND the OS is gentoo. we ran into a an issue where the $config_dir is being managed by another module, and we therefore had duplicate resources. this change addresses that since in all other cases the $config_dir either exists by default (e.g., FreeBSD) or is created when the haproxy package is installed (seemingly every OS except Gentoo).
//cc @jewjitsu