Open Stack

Spencer Krum <krum.spencer at 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