Spencer Krum <krum.spen...@gmail.com> writes: > Hello All, > > At the meeting on August 25th, we discussed an issue with the puppet-httpd > module and a few solutions. The issue is that the httpd_mod type does not > have a baked-in ordering relationship with the Service['httpd'] resource. > This means that sometimes httpd_mod resources are instantiated after the > service attempts to come up, meaning the service cannot start. > > A few solutions have been proposed: > > 1) Modify our use of the httpd_mod resource to use 'before' everywhere. > This patch [1] is an example of doing that for puppet-gerrit, we'd have to > perform similar modifications elsewhere in our code. > > 2) Modify the httpd module to do this automatically. This patch [2] changes > the type at the ruby layer using puppet internal apis to add an > 'autobefore' on the Service['httpd'] resource. > > 3) Create an httpd::mod defined type that can do this automatically. We'd > have to then change every invocation of httpd_mod to be httpd::mod. This > patch [3] is the patch to create httpd::mod and this patch [4] shows what > using it would be like. We'd have to apply changes like [4] everywhere in > our infrastructure. > > 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving > patching that module to support our usecase and the other(4b) where we use > the existing api.
Here are the principals I'm working from: * Puppet should be used to describe the end state of a system and should be used to ensure that reality matches the described state. * Puppet has multiple levels of abstraction and implementation. * The mechanics of how something is done in puppet should be hidden from the next level of abstraction out. This facilitates the outermost use of puppet being as close to mere state description as possible while the inner layers are concerned with the mechanics of achieving that state. When we invoke the gerrit module, we might pass some parameters indicating how it should be used which have implications for the contents of a configuration file. In that case, the module user should not be concerned with what is needed to put that file in place, they may not even know about the file at all. The gerrit module itself should describe how to write that file and what needs to be in place before it is written. Because puppet itself has know way of knowing that before writing a gerrit config file, a java program needs to be run to prepare the filesystem, we must tell puppet about that ordering. So the gerrit module where this happens is the inner-most layer of abstraction that can define that ordering relationship, and so that's where we should do it. Compare that to the simple act of writing a file in a directory. In that case, puppet can (now) auto-require the parent directory. There is no conceivable need to write a file before creating its containing directory, in fact, that makes no sense, and puppet itself can detect that condition and establish the correct ordering. In our case, we know that in order to start the apache service, the complete configuration must be written to disk first. There is no reason to write part of the configuration, start the service, and then write more. Therefore, the innermost layer of abstraction that can encapsulate the logic is the apache module. It should take, as input, the final configuration state of apache. Within, it should describe the order of operations needed to achieve that state. We know that is: 1) install the package 2) configure modules, write vhost and main configuration files 3) start the service There is never a reason for a user to do those in any other order, so the apache module should do that for them. (However, there is a reason for the user to want to avoid starting the service, so we should expose that as an option.) Following this logic, I believe that means we should do options 2 or 3 above. I note that we have an httpd::vhost class already, which suggests that option 3, create httpd::mod, might be the most internally consistent. Yolanda also suggests that this seems to be the way to proceed in her summary reply to this thread. -Jim _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra