On Wednesday, February 4, 2015 at 10:09:04 AM UTC-6, James Oden wrote:
>
> I am getting a dependency loop when trying to apply my puppet
> manifests, however the loop makes little sense to me as one the
> dependencies seems to come from no where.
>
> The cycle is this:
>
> Augeas[Change production to development in virtual hosts] =>
> Exec[re-read apache config] =>
> Class[App::Apache] =>
> Augeas[Change production to development in virtual hosts])
>
>
> This cycle is started with this resource in Class A:
>
>
> augeas { 'Change production to development in virtual hosts':
> context => '/files/etc/httpd/conf.d/httpd-app.conf',
> changes => [
> "set VirtualHost[1]/*[self::directive='SetEnv']/arg[2]
> development",
> "set VirtualHost[2]/*[self::directive='SetEnv']/arg[2]
> development",
> ],
> require => Class['app::apache'],
> notify => Exec['re-read apache config'],
> }
>
> Exec['re-read apache config'] lives in the class app::apache, and it
> looks like:
>
> exec { 're-read apache config':
> command => '/sbin/apachectl graceful',
> require => Class['app::packages'],
> refreshonly => true,
> }
>
>
[...]
> In particular I don't see where it is getting that Exec[re-read apache
> config] requires Class[App::Apache] (which itself contains
> Exec[re-read apache config]).
That dependency arises from the Exec resource being declared by
Class[App::Apache]. You could read it as "Class[App::Apache] has not been
fully applied while Exec[re-read apache config] has not yet been applied."
> But then it goes a step beyond and
> states that Class[App::Apache], the dep I can't explain requires
> Augeas[Change production to development in virtual hosts] causing a
> loop. Near as I can tell App::Apache makes no requirements that
> takes you directly back Augeas[Change production to development in
> virtual hosts].
>
That's right in the Augeas resource you presented, specifically:
require => Class['app::apache'],
>
Class['app::apache'] is too coarse-grained to serve your dependency
requirements, as is evident in your expressing a dependency on a resource
it declares. You want your Augeas resource to be applied after Apache's
configuration file has been configured, and you want the restart to be
triggered when Augeas modifies the file, but both of those resources are
managed by Class['app::apache'].
Since we've lately been discussing DSL code style and practices, I'll
observe that the prevailing opinion these days seems to be that it is
inappropriate for resources to be declared a given scope to be explicitly
targeted by relationships declared in any unrelated scope, especially
across module boundaries. That principle would direct that relationships
*specifically* with Exec['re-read apache config'] not be declared outside
Class['app::apache'] or any subclasses it may have, and particularly not by
classes outside module "app".
One common way to approach the issue would be to establish separate classes
for the distinct logical components of Class['app::apache']. The usual
split is one to manage the physical presence of the software on the target
system, one to manage its configuration, and one to manage its execution as
a service. These might be represented as classes app::apache::software (or
"app::apache::install", which is more conventional but less suitable),
app::apache::configuration (or "app::apache::config", which many people
prefer), and app::apache::service. For the record, where I offer
alternative names for those components, it is because class names should be
*nouns* describing the thing they manage, not verbs.
Given such a split, your Augeas resource would require
Class['app::apache::software'], and notify Class['app::apache::service'].
Note that such a split does not imply removing Class['app::apache'], but
most -- perhaps all -- of its work would be reduced to declaring (and
declaring containment of) the split-out classes.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/326e5883-d945-459d-b561-8346db8e692b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
