On Thu, Feb 5, 2015 at 9:52 AM, jcbollinger <john.bollin...@stjude.org> wrote:
<snip>
>>
>> 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 that implies that any resource of a class has a dependency on its
class. Put another way every element of a container seems to have a
dependency on the container? Sounds very chicken and egg to me (i.e.
a built in cycle).
>
>>
>> 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'],
>
Yes but that is a separate dependency. I have declared:
A->B
A->C
where B contains C
1. That should in no way imply B->A.
2. Having a dependency on something contained in something else seems
odd, but when you think from a packaging perspective that's normal
since what you really need to do is execute this thing contained in
the container. This is why RPM has file dependencies (well it's one
of the reasons).
>
>
> 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'].
>
Yes.
> 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".
I understand the reasoning here, however in this case what is actually
going on is:
1) my real dependency is on app::apache which contains something I want to
execute.
2) I am executing something from app::apache.
What I was trying to do then was call the specific "command" I wanted
to run, and express the dependency that "command" had on its
container/package/class.
Now if just "notify => blah" automatically creates a dependency on the
container of blah that is awesome. However the fact that I had
explicitly declared that dependency should at worst only cause a
duplicate dependency then, not somehow convolve a cycle from that
duplicate dependency.
>
> 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.
I like that way of approaching things. However, after listening to
your explanation it still feels like there is something amiss in the
handling of dependencies here. Two separate trees in a DAG should not
be merged together (unless I'm totally misunderstanding something).
That said, concerning the approach of notifying a class, when doing
this does this mean that all notifiable resources in the class get the
notify message too?
Thanks...James
--
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/CAPWHxf%2BV51sWvJ%2B%2BrL_-nDSdt8S7ORi1oQJ2fN7tS%2BkptQZL3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
