On Thursday, October 25, 2012 9:06:30 AM UTC-5, Abhijeet Rastogi wrote:
>
> On Thu 25 Oct 2012 06:53:24 PM IST, jcbollinger wrote:
> >
> > You're still confusing me. Your initial message led me to believe
> > that your two ucarp instances are supposed to run on different hosts.
> > Did I misunderstand?
>
> In total, there will be four ucarp instances. Two running on two
> different machines. The issue here is that, the file resources defined
> inside the user-defined ucarp::host::config resource is throwing the
> error. I am not sure how do I solve that.
>
> Meanwhile, I had a look at
> https://github.com/bodepd/puppet-ensure_resource and this kind of
> solved my problem.
Any problem solved by that function would be better solved by avoiding
duplicate declarations in the first place. At best it's a band-aid, not a
fix, but it is completely wrong if you cannot be certain that all
declarations of the target resource are identical. If they are all
identical, then the correct solution is to lift the declaration(s) out of
its duplicative context (often a defined type) into a class that the
defined type declares, or can rely on having been declared. If they are *
not* all identical, then you have a *bug* in your manifests, and function
just masks it.
Your problem appears to be a special case of the latter. You have this
definition (excerpted, and name edited):
define ucarp::host::config( $node_id, $password="", $interface_primary,
$interface_vip, $vip_addr, $vip_addr_netmask, $vip_addr_gw, $ensure=present
) {
# ...
file { "vip-up":
ensure => $present,
path => '/etc/sysconfig/carp/vip-up',
content => template("ucarp/vip-up.erb"),
require => Package['ucarp'],
}
# other related scripts ...
}
Now, the template interpolates some of the definition's parameters, making
the output specific to one ucarp instance. Therefore, declaring it
indirectly via ensure_resource() is incorrect: you end up with only the
script for *one* of your ucarp instances, where what you actually need is a
separate script for each one. That's what Puppet has been trying to tell
you all along.
You need to add some kind of instance identifier to the name of the file
you are creating (and to the resource title if you continue to separate
it), such as
file { "/etc/sysconfig/carp/vip${vip_id}-up":
ensure => $present,
content => template("ucarp/vip-up.erb"),
require => Package['ucarp'],
}
(Where you would need to set $vip_id appropriately via an additional
parameter to your definition, or some other means.)
If, contrary to appearances, you really do want only one vip_up script (and
similar) for all instances, then its declaration does not belong in a
per-instance definition. It looks like you could pull it up to class
ucarp::host.
I was able to do what I intended by wrapping the
> file resources defined inside the ucarp::host::config inside
> ensure_resource. Everything worked perfectly on 2.7.9 as expected. I
> was testing everything by having only one module and doing everything
> in site.pp. But, when I moved to the actual environment which includes
> 2.6.13, it isn't able to find the resource type ucarp::host::config and
> complains about invalid resource type. Any idea why that could be
> happening?
>
Yes. If you are trying to declare an instance of nested definition
ucarp::host::config before or without including class ucarp::host, then it
is possible that the autoloader will not find it. You should move it to
its own file in the module (modules/ucarp/manifests/host/config.pp, based
on its name).
>
> The situation is something like:
>
> 1. There is init.pp in module ucarp containing class ucarp. (As it
> should).
Sort of. If your module "ucarp" has a main class (i.e. one with the same
name as the module), then init.pp is where it should appear. It is not
necessary to have such a class, however.
> It has a include "*" written in the first line.
>
I'm surprised that works at all, and your results suggest that it doesn't
do what you think. It would be much better to explicitly 'include' the
classes you want.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/4Yx1heS5gegJ.
To post to this group, send email to puppet-users@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.
