On Thursday, February 12, 2015 at 10:15:19 AM UTC-6, Salty Old Cowdawg
wrote:
>
>
>
> On Tue, Feb 10, 2015 at 9:21 AM, jcbollinger <john.bo...@stjude.org
> <javascript:>> wrote:
>
>> so I have to think that you have some wrong expectation about the effect.
>>
>>
> Based on some reading I did yesterday I must confess that may be true. My
> thinking was using that type of declaration made the fact the file was
> installed "visible" to other resources.
>
ALL resources declared in the process of building a given node's catalog
are globally visible during that catalog-building run, whether the
declarations are concrete, virtual, or exported. If they are virtual or
exported then the resources might not end up in the catalog, depending on
whether they are later realized or collected, but that's a different matter.
The only reason to declare a virtual resource (and it can be a good reason)
is to defer the decision about whether that resource is included in the
catalog to some other point in catalog building. One useful consequence of
such a deferment is that declared virtual and exported resources can be
marked multiple times each for inclusion in the catalog; no matter how many
times they are marked, they appear at most once in the catalog.
People occasionally get the idea that virtual resources provide a way to
declare the same resource more than once. That is wrong, but they do offer
a way to *avoid* multiple declarations: put one shared, virtual declaration
of the resource in some central place, and elsewhere realize / collect it
instead of declaring it *de novo*.
>
> One of the concerns I have (and not in this particular case) if I were to
> declare something like
>
> class apache {
> @package { apache3: ensure => latest}
> }
>
> and then in another module
>
> include apache
> class somevhost {
> realize Package[apache3]
> blah..blah...blan
>
> and then another module tried to do the same thing what would happen?
>
If you declare a virtual resource then it is safe to realize that resource
multiple times. This is one of the main use cases for virtual resources.
With that said, you can get a lot of mileage out of classes being
singletons. In your apache3 example, class 'apache' would probably be
better off declaring Package['apache3'] concretely. Any number of defined
type resources and other classes could still safely 'include' class apache,
and they would not then need to realize Package['apache3']. Remember always
that the 'include' function ensures that the designated class is "included"
in the target node's catalog (but never more than once); it does *not*
interpolate the body of that class in place of the 'include' call, as
sometimes is wrongly assumed.
> Eventually there are going to be other developers working on Puppet
> modules in my current environment and I am wondering how to avoid
> collisions...
>
>
Module compatibility is a big, important, thorny topic. We've had epic
debates about it in the past, but not much discussion recently. I think
the issue has receded a bit with the emergence of consensus good practices
for module design (another topic that's seen a great deal of discussion).
Among those good practices:
- most modules should be narrowly focused
- module classes should be even more focused
- cross-module dependencies should be minimized; any that are declared
should refer only to public classes of the target module
- no public class of any module should ever be declared via a
resource-style class declaration (especially not in module code, but really
not in site manifests, either)
- document, document, document
That's by no means an exhaustive list.
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/c13e5360-df71-4df4-871e-5c3bea76f33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
