Hi,
check this ticket. https://tickets.puppetlabs.com/browse/PUP-6723
It is hard to explain, but the 'and' a resource collector does niot behave like
the 'boolean and' as we expect this.
Grts
Jo
-----Original message-----
From: jcbollinger <john.bollin...@stjude.org>
Sent: Thursday 13th September 2018 15:50
To: Puppet Users <puppet-users@googlegroups.com>
Subject: [Puppet Users] Re: Exported resource realized by resource collector,
bug?
On Wednesday, September 12, 2018 at 3:20:12 PM UTC-5, Julio Guevara wrote:
So I'm working with puppet 5.5.1 and I have encountered what I think is a bug.
So on my site.pp i have the following line for ordering my firewall rules:
site.pp
---------
if $::kernel == 'Linux' {
# Make sure every firewall rule not pre or post is created in the middle
Firewall <| tag != 'pre' and tag != 'post' |> {
before +> Class['profiles::fw_rules::post'],
require +> Class['profiles::fw_rules::pre'],
}
}
Then on another class I'm doing the following (This is a class for a postgresql
client):
@@firewall { "222 tcp:5432 pgpool from ${::ipaddress}/32" :
action => 'accept',
source => "${::ipaddress}/32",
dport => '5432',
proto => 'tcp',
tag => [ $tag, 'postgresql_client' ],
}
On the postgresql servers I do:
# Grab all firewall rules created for this cluster
Firewall <<| tag == $tag and tag == 'postgresql_client' |>>
I would expect that the rule to only appear on the postgresql server, but what
ends up happening is that the rule is realized on both the server and the
client.
On the documentation for resource collector
(https://puppet.com/docs/puppet/5.5/lang_collectors.html#exported-resource-collectors):
Collectors realize virtual resources, are used in chaining statements, and
override resource attributes.
on that very same page we have the following for exported resource collectors:
An exported resource collector uses a modified syntax that realizes exported
resources and imports resources published by other nodes.
Have anybody else found a similar issue?
I do not recall encountering this issue myself, but I concur that I expect
ordinary resource collectors to not collect exported resources, no matter what
node declares them. Although exported resources and exported resource
collectors are both syntactically and semantically analogous to virtual
resources and ordinary resource collectors, they are and have always been
distinct. The documentation presents no reason to think otherwise, and in fact
generally supports that position, though I am unaware of any place where it
states it in so many words.
Therefore, if indeed it is the case that an ordinary resource collector is
collecting exported resources, then I concur that that constitutes a bug, and a
fairly serious one at that. I suggest you file a bug report.
Do note, however, that in the event that an exported resource is collected for
a given target node via an exported resource collector, I do expect that for
all intents and purposes it is then treated as an ordinary resource, and in
particular, that it ordinary collectors will then affect it with respect to
parameter overrides and chaining (in the scope of the current catalog building
job). The thing that ordinary collectors ought not to do with respect to
exported resources is import them.
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
<mailto:puppet-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/0834fac6-15de-4b7f-9ca1-fbce11b13754%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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/zarafa.5b9b6d09.5d47.268d68ba72245991%40zarafa7.open-future.be.
For more options, visit https://groups.google.com/d/optout.
