On 2014-31-03 20:08, Dan Bode wrote:
I disagree that ensure_resource is evil and should not be used. It is
however, potentially problematic, and it's issues are worth discussing.
It was written (full disclosure by me) as an improvement over defined().
While it is not perfect (it suffers from parse-order issues), it is
intended as an improvement of defined, a convenience method which exists
in Puppet core.
Specifically, it is intended to solve the limitation in Puppet that
duplicate resource declarations are treated as failures in Puppet, even
if the resources they describe are identical.
That being said, there are two reasons it may be problematic.
1. Behavior depends on parse order - this is probably the best reason
not to use it. The behavior of how it will fail depends on the order in
which code is parsed in Puppet. That is why this method (as well as
defined(), and resource collection overrides) should only be used by
users who understand this behavior, it's limitations, and how to debug
it when they run into issues. It's usage and the fact that it depends on
the order in which your code is parsed makes it problematic to have in
modules that are intended to be shared. That being said, it looks like
Puppet is moving to a more procedural language,which may make this less
of an issue going forward.
Going forward, I think the Puppet Language should handle the situation
where more than one resource definition / class definition is made and
where the two are considered compatible (they describe the "same
state"). We are discussing solutions for this with the idea to solve
this during Puppet 4x.
The construction of the catalog is lazy (or call it declarative /
functional if you will), and will remain so even if there are other
things done to the language that are imperative.
(Side note: it is *evaluation order* not *parse order*, files are always
parsed in the order the text is written from top to bottom, every line.
I know the term "parse order" is used in the community to be synonym
with evaluation order, but it throws me every time).
Regards
- henrik
2. It is not part of Puppet core and may need access to unsupported APIs
to work as expected. I was not aware until I read that email thread that
it was not working correctly with parameter aliases, it's pretty
reasonable to open this up as an issue and see if someone volunteers to
fix it. That being said, I think it will require access to some
undocumented unsupported APIs in order to implement correctly.
On Mon, Mar 31, 2014 at 7:08 AM, jcbollinger <john.bollin...@stjude.org
<mailto:john.bollin...@stjude.org>> wrote:
On Sunday, March 30, 2014 11:24:30 PM UTC-5, Atom Powers wrote:
Over the years I've heard a lot of people declare one
function/method/implementation of something to be "evil". I've
found that, more often than not, the person declaring it to be
bad has simply been burned by trying to use it for something the
function was never intended to be used for. (Usually an easy
trap due to incomplete documentation.)
So I wonder, are ensure_resource and create_resources really
evil, or just too easy to abuse in evil ways?
On Fri, Mar 28, 2014 at 9:06 AM, jcbollinger
<john.bo...@stjude.org> wrote:
Ensure_resource() is evil. Do not use it.
Ensure_resource() is evil. Create_resources() is not. The post
from which you excerpted my comment
(https://groups.google.com/forum/#!searchin/puppet-users/ensure_resource/puppet-users/dOCIZ8-Gfgw/VhlBbrSRpb8J
<https://groups..google.com/forum/#!searchin/puppet-users/ensure_resource/puppet-users/dOCIZ8-Gfgw/VhlBbrSRpb8J>)
explains why ensure_resource() is evil: in short, because it looks
like it does something useful, but in fact hands you a gun loaded
with foot-seeking bullets. It takes /at least/ as much work to use
ensure_resource() safely as it does to avoid any need for it in the
first place.
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/f5d5c0aa-2355-4dc8-91da-2311fc3f679a%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/f5d5c0aa-2355-4dc8-91da-2311fc3f679a%40googlegroups..com?utm_medium=email&utm_source=footer>.
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
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CA%2B0t2LxOkQOosGsGuDRSWc24jq8t%2BUa2CXuV10SkSQK8DMCREg%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-users/CA%2B0t2LxOkQOosGsGuDRSWc24jq8t%2BUa2CXuV10SkSQK8DMCREg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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/lhckn8%24fb0%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
