Commit
virtualhost logroot location
- Loading branch information
There are no files selected for viewing
10 comments
on commit c2c75a6
There was a problem hiding this comment.
This change is giving me a slight headache:
- It forces anyone with more than one vhost to override
$logroot, or Puppet will complain ofFile['/var/log/apache2']being defined twice. - Often the parent directory of
$docrootis a symlink that is managed outside Puppet (e.g. with Capistrano or other deployment tools). After this change, the user must create the parent directories of$docrootor the file resource here will fail, which means there's no way of keeping Puppet from reverting app deployments!
There was a problem hiding this comment.
Hmm, I'm not seeing the same problem.
I also deploy, actually via puppetlabs/vcsrepo, things managed externally.
I use it as:
apache::vhost { 'www.example.com':
priority => '10',
vhost_name => 'w.x.y.z',
port => '80',
docroot => '/home/wwwexamplecom/docroot/',
logroot => '/home/wwwexamplecom',
servername => 'www.example.com',
serveradmin => 'webmaster@example.com',
serveraliases => ['example.com', ],
template => 'apache/vhost-example.conf.erb',
configure_firewall => false,
}
apache::vhost { 'www.example.com-IPv6':
priority => '10',
vhost_name => 'a:b:c:w:x:y:z:d',
port => '80',
docroot => '/home/wwwexamplecom/docroot/',
logroot => '/home/wwwexamplecom',
servername => 'www.example.com',
serveradmin => 'webmaster@example.com',
serveraliases => ['example.com', ],
template => 'apache/vhost-example.conf.erb',
configure_firewall => false,
ensure_dirs => false
}
Perhaps to solve the first problem you need to have ensure_dirs set to false?
Actually, I think in your case if you set ensure_dirs to false it will solve both issues?
Does that work for you?
There was a problem hiding this comment.
An ensure_dirs option would indeed solve both issues, but I can't see it in the current HEAD, so I guess I'll have to wait for your pull request to be merged :)
Personally I'd suggest making the ensure_dirs option false by default; then it won't break backwards compatibility and be less of a surprise for users who already have their own docroot resource.
Thanks!
There was a problem hiding this comment.
I'm seeing the same behavior as @jarib but with docroots as well as logroots. Creating multiple vhosts that use the same docroot will yield an error. I also agree that ensure_dirs would solve the problem, but it seems more like a hack.
Wouldn't the better solution be to use virtual resources and realize a single directory resource?
If ensure_dirs is to be used, though, I agree that it should be false by default for compatibility. Also, maybe it should be broken out of the ipv6 pull request? Maybe it would make it to HEAD sooner... but unless I am mistaken, virtual resources should be the better way.
There was a problem hiding this comment.
Just to explain my second scenario:
A typical Rails deployment with Capistrano will set up things like this:
symlink: /webapps/my-app/current -> /webapps/my-app/releases/201208011200/
$docroot: /webapps/my-app/current/public
So it seems that even with ensure_dirs set to false, the fact that File["${priority}-${name}.conf"] depends on File[$docroot] means that I must create the docroot with puppet.
On deployment, the symlink is updated to the correct timestamped directory. If puppet is then run some time after deploy, it will revert the symlink to whatever it thinks is right. So I can't see how to make this work as long as this module won't allow me to point the docroot at a non-existing directory.
EDIT: Ooops, never mind. Looks like ensure_dirs => false will remove the dependencies on $docroot, so the issue goes away.
I agree with @jtopjian that ensure_dirs seems somewhat hacky.
There was a problem hiding this comment.
There was a problem hiding this comment.
Why isn't docroot set to '/webapps/my-app/current' ?
The mod_rails/passenger Apache module wants docroot pointed at Rails' public/ directory, whereas /webapps/my-app/current holds the actual application code. Though even if I could use that as docroot, Puppet would still need to know what release to point the symlink at, which is what breaks the intended separation between configuring the server (with Puppet) and deploying new versions of the app (with Capistrano).
Anyway, I realize ensure_dirs => false will do the trick. I don't have enough Puppet experience to tell whether virtual resources is a better solution.
There was a problem hiding this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
Virtual resources still have to be only defined a single time per node, usually via a parameterized class. But this would have to be done at the level of the original apache::vhost definitions (increasing the LOC and human overhead) otherwise you run the risk of creating duplicate resources in the same way that you are trying to avoid.
The use of defined() or ensure_resource() in #54 is a much more direct way to code around this problem of ambiguously-named potentially-conflicting resources.
this actually looks like it should not have been merged. By default, everything in a defined resource type should be parameterized so that multiple instances can be declared.