On 2018-09-14 10:10, Johan De Wit wrote:
> 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.
>
It is not AND that is different; it is the == and != query operators
that must be understood. The == acts as "in" but != is an *exact* match
operator just like in puppet.
So, to find those that have neither 'pre' nor 'post' you would want to
write the following, only you cannot because the NOT operator is not
supported !!!
<| not(tag == 'pre' or tag == 'post') |> # gives error for not()
The expression:
tag != 'pre' and tag != 'post'
works only if tag is not an array (which it almost always is)
Consider this:
@notify { 'a': tag => 'blue' }
@notify { 'b': tag => 'green'}
@notify { 'c': tag => ['blue', 'green'] }
@notify { 'd': tag => 'red' }
@notify { 'e': tag => ['red', 'blue'] }
Notify <| tag != 'blue' and tag != 'green' |> { }
It will realize c, d, and e.
c because the array is != 'blue' and is also != 'green'
d because 'red' != 'blue' and 'red != 'green'
e because again, the array is != to either 'blue' nor 'green'
If you think that you can compare using an array, like this:
<| tag != ['blue', 'green'] |>
then you will also be disappointed because that is also not supported
and will give you an error since array values are not supported in the
query.
The documentation actually points out that the behavior is undefined for
arrays and hashes. That is its way of saying "it is a mess". How it
actually works (since way back) is what I described above.
You need to find a different way of structuring your logic.
I doubt that virtual/exported resources and features around those will
receive much love as there has been talks about dropping both virtual
and exported resources all together (at the moment we have no better
replacement for the features they enable, so this will not happen over
night).
Worth noting is also that using tags extensively is not a very robust
solution since there is no way you can know if your tags are unique or
not or if you will find elements by chance that are tagged with
something from part of a name in some scope. If you must use tags,
use tags that are as unique as possible. (More than one user have been
bitten by this).
Sorry for being the bearer of bad news.
Best,
- henrik
>
> Grts
>
> Jo
>
>
> -----Original message-----
> *From:* jcbollinger <John.Bo...@stJude.org>
> *Sent:* Thursday 13th September 2018 15:50
> *To:* Puppet Users <
puppet...@googlegroups.com>
> *Subject:* [Puppet Users] Re: Exported resource realized by resource
> <
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
> <
https://puppet.com/docs/puppet/5.5/lang_exported.html> 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...@googlegroups.com
> <mailto:
puppet-users...@googlegroups.com>.
> <
https://groups.google.com/d/msgid/puppet-users/0834fac6-15de-4b7f-9ca1-fbce11b13754%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> 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...@googlegroups.com
> <mailto:
puppet-users...@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
> <
https://groups.google.com/d/msgid/puppet-users/zarafa.5b9b6d09.5d47.268d68ba72245991%40zarafa7.open-future.be?utm_medium=email&utm_source=footer>.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/