On Nov 25, 6:22 pm, Lars Francke <lars.fran...@gmail.com> wrote:
> I don't understand how I'd convert the definitions from my original
> mail into virtual resources.
You wouldn't convert the definitions themselves, but rather their
instantiations. Alternatively, you might convert the definitions to
*use* virtual resources, but instantiate them non-virtually. For
example,
define foo() {
@file { "${name}/foo": }
}
define bar(...) {
realize File["${name}/foo"]
...
}
class baz {
foo { "bat": }
bar { "bat": }
}
Having now looked a little more deeply at your problem, however, I
think that's putting the cart before the horse. You need to
redesign / refactor (more on that below).
> Simplified:
> $disks = ['/a', '/b']
>
> define foo() {
> file { "${name}/foo": }}
>
> foo { $disks: }
>
> define bar($path) {
> file { "${name}/foo/${path}":
> require => Foo[$name],
> }}
>
> bar { $disks:
> path => "bar",
>
> }
>
> And I require those things in multiple classes.
> I think this works but apart from being ugly it does not work when
> requiring foo from multiple classes. I also cannot require bar
> multiple times with different paths because the name is the same (the
> array) and I don't know how to get around that. Which kinda defeats
> the variability of the define.
You should not think of defines as macros or functions, or even as a
special kind of class. They are essentially custom resource types,
akin to File and Service. As such, (a) the titles provided in their
instantiations must each identify a specific logical object to manage,
(b) you cannot instantiate a define multiple times with the same
title, and thus (c) one set of their parameters must provide all the
needed details for one object. All that is just like any other
resource declaration.
> I also don't understand how to convert foo to a virtual resource
> definition. I need to change it to this:
> @foo { $disks: }
>
> and then in bar just add this: Foo <| |> ?
Yes, that's about right. You can also put selection predicates inside
the brackets to limit which Foos are realized. Alternatively, you can
use the "realize" function instead of bracket notation if you know
exactly which virtual Foos you want to realize.
But none of that is going to solve your particular problem, because
even if you instantiate your defines virtually, you still can provide
only one set of parameters for each title within the scope of each
node. Basically, this part of your design concept (define "bar") does
not fit the Puppet model.
I think the bar / hadoop_sub_directory define needs to be removed
altogether. You may be able to replace some or all of its intended
function with ordinary File resources in conjunction with suitably-
scoped File property defaults. You may simply need to be a little
more verbose and / or repetitious in your manifests. You may need or
want to refactor some of the classes that use these defines.
> Any help would be really appreciated. I must have read the
> documentation four bajillion times now but parts of it it still make
> no sense to me. I especially have trouble understanding Virtual
> resources,
Getting your head around virtual resources can take some effort, but
once you've got it, they're really not that hard. A virtual resource
declaration (including a virtual definition instantiation) is
identical to an ordinary one except
1) it has an @ sigil in front of it, and
2) its effect is only to set the properties of the declared resource,
not to instruct Puppet (as non-virtual declarations do) to *apply* the
resource to the current node.
To make that useful in light of (2), a set of manifests in which a
virtual declaration is included can instruct Puppet to apply the
resource either by means of the <| |> notation or by calling the
"realize" function. The two realization methods have identical
effects on affected resources. Each realization is an instruction to
Puppet that the specified resource should be included, once only, in
the catalog for the relevant node. Multiple realizations are thus
redundant, but consistent, as each one tells Puppet the same thing.
> calling a define/resource with an array
You may help yourself by thinking in terms of "declaring" a resource
or definition instance, rather than in terms of "calling" these.
"Calling" is associated (at least for me) with functions, and these
don't work like functions.
In any event, declaring a resource or definition instance using an
array for the title is just shorthand for multiple declarations, one
for each element of array, each with identical properties except for
the title. In the body of a definition, the title may be referenced
as $name, and therefore it may influence the properties of resources
declared within. That in no way changes the semantics and
requirements of resource declarations.
> and requiring
> virtual resources and defines.
If you mean "realizing" virtual declarations, I've covered that above
as best I can. If you actually do mean "requiring" them, then the
only difference from non-virtual resources is that you can only
"require" a virtual resource for a target node where that resource is
realized.
HTH,
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
