Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Coming late to the discussion, I know. Sorry.) On 2012-01-26 11:19, Felix Frank wrote: [Regarding common modules for installing packages.] > Thinking about other examples of similar systems (CPAN, Gems, Pear, you > name it), module dependencies are commonplace (and usually coupled with > a system that will automatically resolve them for the end user). A big difference is that in those other systems, you don't typically see modules on the level of def add_17(n) return n + 17 end And of course, we need another module for doing def add_23(n) return n + 23 end Puppet modules for making sure a single package is installed is on the same sofistication level as the above two. It's silly. What would the reaction of the Python, Perl and Ruby communities be if someone wanted modules like that in PyPI, CPAN and RubyGems? Why should we want such sillinesses in the Puppet Forge? /Bellman -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk90ocUACgkQDGpP8Cv3aqK7mgCdEQlPE70a1bJncrmeC2fvqv+V 9OoAn36vzrLoyCsB976MUCmOjeJo/IN5 =tbQM -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(I know I'm late in responding; I'm a couple of months behind in reading
the mailing-list, and still have 2000 unread. I have read this entire
thread, though.)
On 2012-01-19 18:18, Nigel Kersten wrote:
> I'm looking for strong opinions on whether we should or shouldn't deprecate
> the defined() function for Telly, the next major Puppet release this year.
>
> jcbollinger put it quite well in another thread:
>
> "Use of the "defined" function introduces a parse-order dependency, and the
> additional work you need to do to ensure that that dependency is always
> fulfilled overcomes any simplicity advantage that might otherwise exist."
- -1 until there is some other, usable, way of realizing the good things
you can achieve with defined().
My use case for defined() is in definitions that wants to make sure
a package it needs is installed, and where that package varies between
instances of the definitions. For example, I have a definition named
nrpe::check, which configures a Nagios NRPE check. It wants to make
sure the appropriate nagios-plugins-PLUGIN is installed, so it does
(simplified, and just retaining the code dealing with the package):
define nrpe::check($plugin='', $checker='', $args=[], $prefixcmd=[])
{
$pluginpkg = $plugin ? {
'' => "nagios-plugins-${name}",
0 => '',
default => $plugin,
}
if $pluginpkg != '' and ! defined(Package[$pluginpkg]) {
package {
$pluginpkg: ensure => installed,
}
}
}
A user would do things like:
nrpe::check { 'load': args => [ '-w20,10,8', '-c30,18,10' ]; }
and the "nagios-plugins-load" package will automatically be installed.
This becomes interresting when you have:
nrpe::check { 'test_foo': args => ['foo'], plugin =>
'nagios-plugins-ourtest'; }
and
nrpe::check { 'test_bar': args => ['bar'], plugin =>
'nagios-plugins-ourtest'; }
both using the same plugin, but with different parameters, in different
parts of the manifest for the node. The cincher here is that there are
several dozens of Nagios plugin packages available (EPEL has 63, many
organizations probably have several of their own, and so on).
It would be possible to instead have the nrpe::check definition do
include "nagios_plugin_package::${plugin}"
and force the user to define a class for each plugin they use (and I
could of course "pre-seed" by writing 63 of those myself in my nrpe
module). But it becomes much easier on the users of the nrpe module
if they don't need to do so.
This use of defined() is safe, since there is really only a single
declaration of each Package['nagios-plugins-PLUGIN'] resource.
I'm not fond of defined(), as it is easy to get wrong, but it is also
quite useful in some cases. It would be a shame to deprecate a useful
feature before there is a workable way to achieve the same end results
in place.
/Bellman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk90nj8ACgkQDGpP8Cv3aqL2WQCeMkEru8FitrIIzuG3HNdQGiPe
18oAnR94buhofKlbMBa/S+6zEtxX5jYa
=iTQw
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
On 01/26/2012 11:21 AM, Nick wrote:
> For example, suppose in one place I need a file to exist, and in another I
> also
> need it to be executable. Oh dear, I can't do that.
That, and you'd need to merge require/before etc. Such things aren't
trivial. Nan put it this way:
On 01/25/2012 03:59 PM, Nan Liu wrote:
>> Module a:
>> >
>> > file { "/foo/bar":
>> > ensure => 'present',
>> > owner => 'root',
>> > content => "blah blah",
>> > }
>> >
>> >
>> > Module b:
>> >
>> > file { "/foo/bar":
>> > ensure => 'present',
>> > mode => '0774',
>> > }
>> >
>> >
>> > Currently Puppet doesn't allow them to co-exist. It would be nice
if instead it
>> > could be told to check these definitions are consistent, and then
enforce the
>> > union of the two. The same principle could apply to users, groups,
packages,
>> > and presumably any other resources.
> How would this be implemented in a sane way to deal with any
> attributes that are hash/array? Merge, merge+unique, fail? What if we
> add relationship (require/before) or other meta-parameters to the mix?
> If I use the puppet config_version feature to track what resource is
> changed by which line of puppet code for auditing purpose, how would I
> audit a single attribute that can be due to multiple line of code?
> Once I started thinking about define types (which behave like a
> resource), it's gets rather complex especially with conditional
> branching in the define type.
>
> Don't get me wrong, this clearly would be a useful feature, but I'm
> interested only if the rules of how this would behave can be clearly
> expressed and understood, otherwise this will be a maze of pain trying
> to figure out what part of the code broke something.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
On 26/01/12 01:25, Ashley Penney wrote: > All I know is that telling users "If you download 5 modules from puppet forge > make sure you go through them all, extract any duplicating resources into > random modules that exist purely to allow you to realize packages" instead > leads > to a really bad user experience. +1 from me. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
On 26/01/12 00:55, Trevor Vaughan wrote:
> I mentioned in a previous thread that I don't see an issue with having
> multiple identical resources compiled across the code base and I'd like to add
> that to this thread since it's related.
>
> class a {
> package { 'foo': ensure => 'present' }
> }
>
> class b {
> package { 'foo': ensure => 'present' }
> }
>
> include 'a'
> include 'b'
>
> Should work. However, if the two resources differ, this should be a compile
> error. In a perfect world, you wouldn't have this issue, but it shouldn't
> be an error since you're applying identical code.
I think this is a small improvement, but it is still forcing strong coupling -
two parts of the manifest have to know about each other and agree on how things
are defined. It means writing self-contained manifests will still be hard or
impossible, unless *everyone* adopts the (arbitrary) convention of defining only
"ensure => present" or somesuch.
For example, suppose in one place I need a file to exist, and in another I also
need it to be executable. Oh dear, I can't do that.
N
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
Hi,
On 01/26/2012 02:25 AM, Ashley Penney wrote:
> This is a fantastic reply and I appreciate the work you put into it. I
> have just one
> question. As it stands functions can only apply to partial catalogs and
> not to the
> full catalog. Is this a fundamental design decision that cannot be
> changed? Perhaps
> it would be interesting to speculate on what could be done if you had
> the ability to
> use the entire catalog when fully parsed.
This goes in a similar direction as Trevor's comment:
On 01/26/2012 01:55 AM, Trevor Vaughan wrote:
> It feels like Puppet is working its way toward a two pass compile, one
for static code portions and one for dynamic portions. While potentially
less
> efficient, it would add greater room for the flexibility that people
seem to want overall.
Please let's NOT go down that road. You won't get away with two passes.
Think about it: After every pass, some if { } could switch values
depending on what defined() or some other function now returns.
The compiler would need to recursively repeat all its work (don't even
get me started on infinite loops).
That's another road to pain right there IMO.
> I still dislike the third module refactoring. I think it removes a lot
> of power of self-
> contained modules and makes things significantly uglier and more
> difficult when
> combining modules from multiple sources. I wish it could be solved in a
> better
> way within Puppet and I believe it could be with (perhaps optional)
> merging of
> identical resources.
Modules that work in and of itself are desirable, seeing as they're very
elegant. On the other hand, in the worst case you duplicate lots of code
(yes, package { "java": } is not a lot of code), which modules should
normally keep you from doing.
> All I know is that telling users "If you download 5 modules from puppet
> forge
> make sure you go through them all, extract any duplicating resources into
> random modules that exist purely to allow you to realize packages"
> instead leads
> to a really bad user experience.
Uhm, what? o_O
That's not at all what I had in mind. This is a job for *authors*, not
end users.
Thinking about other examples of similar systems (CPAN, Gems, Pear, you
name it), module dependencies are commonplace (and usually coupled with
a system that will automatically resolve them for the end user).
I stronly believe that the Forge is in need of such a system (I believe
Nigel brought up the proposal of metadata for this), and it should be
best practice to design modules to rely on this as much as possible.
BTW Nigel: Separating this thread from the "Cross-module (package)
dependencies" hasn't really worked out, has it? ;)
Sincerely,
Felix
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
On Wed, Jan 25, 2012 at 5:25 PM, Ashley Penney wrote: > > All I know is that telling users "If you download 5 modules from puppet > forge > make sure you go through them all, extract any duplicating resources into > random modules that exist purely to allow you to realize packages" instead > leads > to a really bad user experience. > Absolutely. We're aware this is a big limitation for great collaboration on module content, and it needs to be addressed. Don't you think it makes more sense to make that part of module metadata rather than trying to do it inside all your manifests? If we have: * puppet module tool supporting dependencies and generating module metadata * classes not loading if their dependencies aren't satisfied (or at the least big warnings) do we really need defined()? -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
This is a fantastic reply and I appreciate the work you put into it. I
have just one
question. As it stands functions can only apply to partial catalogs and
not to the
full catalog. Is this a fundamental design decision that cannot be
changed? Perhaps
it would be interesting to speculate on what could be done if you had the
ability to
use the entire catalog when fully parsed.
While writing that paragraph I guess I can see how that wouldn't work,
you'd always
have to evaluate anything that required those functions at the end of the
catalog and
if they had dependencies that would be impossible.
I still dislike the third module refactoring. I think it removes a lot of
power of self-
contained modules and makes things significantly uglier and more difficult
when
combining modules from multiple sources. I wish it could be solved in a
better
way within Puppet and I believe it could be with (perhaps optional) merging
of
identical resources.
But hey, I'm not the guy who has to implement this so I can appreciate that
there
are probably all kinds of design reasons this doesn't work.
All I know is that telling users "If you download 5 modules from puppet
forge
make sure you go through them all, extract any duplicating resources into
random modules that exist purely to allow you to realize packages" instead
leads
to a really bad user experience.
On Wed, Jan 25, 2012 at 3:17 PM, Jeff McCune wrote:
> On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten
> wrote:
> > I'm looking for strong opinions on whether we should or shouldn't
> deprecate
> > the defined() function for Telly, the next major Puppet release this
> year.
> >
> > jcbollinger put it quite well in another thread:
> >
> > "Use of the "defined" function introduces a parse-order dependency, and
> the
> > additional work you need to do to ensure that that dependency is always
> > fulfilled overcomes any simplicity advantage that might otherwise exist."
>
> I'm coming into this thread a bit late so I'm going to take the
> strategy of replying to the OP and pasting a lot of the major comments
> about the related issues into this reply and then addressing those
> directly, inline.
>
> The TL;DR version is that I strongly believe defined() is an
> anti-pattern and should be removed from Puppet core.
>
> For those who would still like to have it available I think it should
> be added to the stdlib module as two new functions: already_defined()
> and already_declared(). The already_ prefix is to clearly communicate
> these are parser-order dependent functions and they _do not_ operate
> on the final catalog itself.
>
> Finally, for those who want 100% backwards compatibility, we publish a
> new module in addition to, and compatible with, stdlib that provides
> the existing behavior of defined().
>
>
> And now for the longer version of why I have this strong opinion:
>
> Throughout the replies in this thread, many people are using defined()
> to test of a resource or class has been added to the catalog and if
> not, add a resource with the same type and title to the catalog. I'm
> going to call this the "if not defined then declare" anti-pattern.
> I'll explain why it's an anti-pattern at the conclusion. I hope
> showing the pattern to be an anti-pattern will be sufficient to show
> the pattern should be avoided when publishing modules.
>
> Nick Fagerlund said:
> > Defined() doesn't suck! It's a 100% reliable way to check what classes
> and defined types are available to the autoloader.
>
> This is an accidental feature and orthogonal to the intent of defined.
> There's also not much evidence that the Puppet community is
> leveraging defined() in this manner. Finally, we should implement a
> first-class and supported function to provide this feature in a clear
> way. is_available() perhaps.
>
> Ashley Penney said:
> > if ! defined(Mysql_user ["${user}@${host}"]) { mysql_user {
> > "${user}@${host}":
> ... } }
>
> This is the "if not defined then declare" anti-pattern.
>
> Felix Frank said:
> > If your master processes this before the *other* declaration of that
> mysql_user{}, you're back to square one and get errors about multiple
> resource declaration.
>
> This is part of why "if not defined then declare" is an ant-pattern.
>
> Nan Liu said:
> > "We should at least differentiate defined vs. declared"
>
> Yes, certainly. We also need to keep in mind that a function can only
> operate on a partial catalog. A function can never operate on a
> complete catalog. Therefore, we need to think of these as "defined
> _yet_" and "declared _yet_" with respect to parse order.
>
> My proposal here is to add already_defined() and already_declared() to
> stdlib. The names are only an example, I don't really care what
> they're called so long as their names take into account the fact that
> a function can only operate on a partially compiled catalog.
>
> Dan Bode said:
> > * static resources in a defined resource type (avoids having to use
> classes
> to store a
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff,
Thanks for the concise write-up, it was really helpful for parsing through all
of the different arguments.
I would like to second the idea that Aaron Grewell had earlier that some sort
of exception handling be allowed and that some other method for doing
the "if I have class A, then do something with class A, otherwise, don't"
scenario is provided. Adding the methods to stdlib would work it just needs
to be available before Telly drops.
I mentioned in a previous thread that I don't see an issue with having multiple
identical resources compiled across the code base and I'd like to add
that to this thread since it's related.
class a {
package { 'foo': ensure => 'present' }
}
class b {
package { 'foo': ensure => 'present' }
}
include 'a'
include 'b'
Should work. However, if the two resources differ, this should be a compile
error. In a perfect world, you wouldn't have this issue, but it shouldn't
be an error since you're applying identical code.
I would also like to make a related request...
Whenever the Puppet core is to change in a way that will break existing code, I
would like a utility to parse my entire code base, whether or not is
is being actively used, to identify potential areas of concern. Right now,
there are deprecation warnings, but those are only output when the code is
run, not if the code is simply in the code base.
puppet-lint helps with some of this and is appreciated but not quite adequate
and the edge cases are difficult to catch.
It feels like Puppet is working its way toward a two pass compile, one for
static code portions and one for dynamic portions. While potentially less
efficient, it would add greater room for the flexibility that people seem to
want overall.
Thanks,
Trevor
On 01/25/2012 03:17 PM, Jeff McCune wrote:
> On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten wrote:
>> I'm looking for strong opinions on whether we should or shouldn't deprecate
>> the defined() function for Telly, the next major Puppet release this year.
>>
>> jcbollinger put it quite well in another thread:
>>
>> "Use of the "defined" function introduces a parse-order dependency, and the
>> additional work you need to do to ensure that that dependency is always
>> fulfilled overcomes any simplicity advantage that might otherwise exist."
>
> I'm coming into this thread a bit late so I'm going to take the
> strategy of replying to the OP and pasting a lot of the major comments
> about the related issues into this reply and then addressing those
> directly, inline.
>
> The TL;DR version is that I strongly believe defined() is an
> anti-pattern and should be removed from Puppet core.
>
> For those who would still like to have it available I think it should
> be added to the stdlib module as two new functions: already_defined()
> and already_declared(). The already_ prefix is to clearly communicate
> these are parser-order dependent functions and they _do not_ operate
> on the final catalog itself.
>
> Finally, for those who want 100% backwards compatibility, we publish a
> new module in addition to, and compatible with, stdlib that provides
> the existing behavior of defined().
>
>
> And now for the longer version of why I have this strong opinion:
>
> Throughout the replies in this thread, many people are using defined()
> to test of a resource or class has been added to the catalog and if
> not, add a resource with the same type and title to the catalog. I'm
> going to call this the "if not defined then declare" anti-pattern.
> I'll explain why it's an anti-pattern at the conclusion. I hope
> showing the pattern to be an anti-pattern will be sufficient to show
> the pattern should be avoided when publishing modules.
>
> Nick Fagerlund said:
>> Defined() doesn't suck! It's a 100% reliable way to check what classes and
>> defined types are available to the autoloader.
>
> This is an accidental feature and orthogonal to the intent of defined.
> There's also not much evidence that the Puppet community is
> leveraging defined() in this manner. Finally, we should implement a
> first-class and supported function to provide this feature in a clear
> way. is_available() perhaps.
>
> Ashley Penney said:
>> if ! defined(Mysql_user ["${user}@${host}"]) { mysql_user {
>> "${user}@${host}": ... } }
>
> This is the "if not defined then declare" anti-pattern.
>
> Felix Frank said:
>> If your master processes this before the *other* declaration of that
>> mysql_user{}, you're back to square one and get errors about multiple
>> resource declaration.
>
> This is part of why "if not defined then declare" is an ant-pattern.
>
> Nan Liu said:
>> "We should at least differentiate defined vs. declared"
>
> Yes, certainly. We also need to keep in mind that a function can only
> operate on a partial catalog. A function can never operate on a
> complete catalog. Therefore, we need to think of these as "defined
> _yet_" and "decla
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten wrote:
> I'm looking for strong opinions on whether we should or shouldn't deprecate
> the defined() function for Telly, the next major Puppet release this year.
>
> jcbollinger put it quite well in another thread:
>
> "Use of the "defined" function introduces a parse-order dependency, and the
> additional work you need to do to ensure that that dependency is always
> fulfilled overcomes any simplicity advantage that might otherwise exist."
I'm coming into this thread a bit late so I'm going to take the
strategy of replying to the OP and pasting a lot of the major comments
about the related issues into this reply and then addressing those
directly, inline.
The TL;DR version is that I strongly believe defined() is an
anti-pattern and should be removed from Puppet core.
For those who would still like to have it available I think it should
be added to the stdlib module as two new functions: already_defined()
and already_declared(). The already_ prefix is to clearly communicate
these are parser-order dependent functions and they _do not_ operate
on the final catalog itself.
Finally, for those who want 100% backwards compatibility, we publish a
new module in addition to, and compatible with, stdlib that provides
the existing behavior of defined().
And now for the longer version of why I have this strong opinion:
Throughout the replies in this thread, many people are using defined()
to test of a resource or class has been added to the catalog and if
not, add a resource with the same type and title to the catalog. I'm
going to call this the "if not defined then declare" anti-pattern.
I'll explain why it's an anti-pattern at the conclusion. I hope
showing the pattern to be an anti-pattern will be sufficient to show
the pattern should be avoided when publishing modules.
Nick Fagerlund said:
> Defined() doesn't suck! It's a 100% reliable way to check what classes and
> defined types are available to the autoloader.
This is an accidental feature and orthogonal to the intent of defined.
There's also not much evidence that the Puppet community is
leveraging defined() in this manner. Finally, we should implement a
first-class and supported function to provide this feature in a clear
way. is_available() perhaps.
Ashley Penney said:
> if ! defined(Mysql_user ["${user}@${host}"]) { mysql_user {
> "${user}@${host}": ... } }
This is the "if not defined then declare" anti-pattern.
Felix Frank said:
> If your master processes this before the *other* declaration of that
> mysql_user{}, you're back to square one and get errors about multiple
> resource declaration.
This is part of why "if not defined then declare" is an ant-pattern.
Nan Liu said:
> "We should at least differentiate defined vs. declared"
Yes, certainly. We also need to keep in mind that a function can only
operate on a partial catalog. A function can never operate on a
complete catalog. Therefore, we need to think of these as "defined
_yet_" and "declared _yet_" with respect to parse order.
My proposal here is to add already_defined() and already_declared() to
stdlib. The names are only an example, I don't really care what
they're called so long as their names take into account the fact that
a function can only operate on a partially compiled catalog.
Dan Bode said:
> * static resources in a defined resource type (avoids having to use classes
to store all static dependencies)
This looks like the anti-pattern, but is not IFF the static resource
being declared is entirely "private" to the module. If the static
resource is something more "public" or "common" like a resource for a
database user/password then this _is_ the anti-pattern.
> * the big reason I keep on leaning on it is for package dependencies.
Using defined() for package dependencies is always an anti-pattern.
Package dependencies are always "common" and therefore two modules
that have the same package dependency need to express this as a third
class. If they don't, then catalogs will have the same resource
contained in different classes from compilation to compilation because
of the parse order nature of functions.
> How about deprecating defined?(Type['title']), but allowing it to accept a
> resource hash?
For the case of package dependencies, moving the dependencies to
another module / class is much more preferable to this pattern because
there is a high probability other modules will need the dependencies
satisfied as well. If the dependencies are not in their own module or
class then the modules that share common package dependencies must
repeat this anti-pattern and must know the exact way in which the
package resource has been declared.
Felix Frank wrote:
> ... endorsing defined() abuse in such a manner will lead to bad (and ugly)
> code all over the place ...
I share this opinion. Strongly. While the if not defined then
declare anti-pattern works, and works well for the internal
organization of a set of
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
Hi Dan,
sorry if I come around bluntly about this, but:
On 01/20/2012 10:00 AM, Dan Bode wrote:
> * static resources in a defined resource type (avoids having to use
> classes to store all static dependencies)
>
> * the big reason I keep on leaning on it is for package dependencies.
> Often something needs an additional package installed (and it is
> possible that other modules may have that same package dependency, and I
> don't want to have to create a new class every time that I need another
> package (especially for something complicated that may have tons of
> package dependencies)
I disagree. The coding overhead for a simple wrapper class is not much
larger than adding if defined(); of course, there is the matter of
organizing those wrappers in your modules, though.
Still, endorsing defined() abuse in such a manner will lead to bad (and
ugly) code all over the place (how do you protect against redeclaration
outside your own defined type?)
> puppet-apt has a relevant pull request where someone wants to wrap a
> defined? around python-software-properties for this exact reason
>
> https://github.com/puppetlabs/puppet-apt/pull/10
Again, I find the endorsement of clumsy design questionable. Common
dependencies should be isolated and exported into a mutual dependency
(module).
If there are real life difficulties that make such workflows impossible
at the moment, I still think that it's a bad idea to root flaw-prone
workarounds ever deeper into the module pool.
> How about deprecating defined?(Type['title']), but allowing it to accept
> a resource hash? This would definitely satisfy my use cases while
> alleviating concerns about resource attribute conflicts/parse order
> dependencies
>
> if defined?(
> {
> package['foo'] => { ensure => present }
> }
> ) {
> package { 'foo': ensure => present }
> }
Interesting. This will add some complexity to the DSL, which I'd be wary
of, but if there are truly compelling use cases, this might be
worthwile? I'm not sure. Does this not suffer from the same problems the
current defined() has?
Sincerely,
Felix
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
How about deprecating defined?(Type['title']), but allowing it to accept a
resource hash? This would definitely satisfy my use cases while alleviating
concerns about resource attribute conflicts/parse order dependencies
if defined?(
{
package['foo'] => { ensure => present }
}
) {
package { 'foo': ensure => present }
}
On Fri, Jan 20, 2012 at 1:00 AM, Dan Bode wrote:
> I wind up using defined more than I should probably admit. yes it is
> dangerous/confusing b/c of parse order dependencies, but it is also really
> useful for a few use cases
>
> * static resources in a defined resource type (avoids having to use
> classes to store all static dependencies)
>
> * the big reason I keep on leaning on it is for package dependencies.
> Often something needs an additional package installed (and it is possible
> that other modules may have that same package dependency, and I don't want
> to have to create a new class every time that I need another package
> (especially for something complicated that may have tons of package
> dependencies)
>
> puppet-apt has a relevant pull request where someone wants to wrap a
> defined? around python-software-properties for this exact reason
>
> https://github.com/puppetlabs/puppet-apt/pull/10
>
>
> On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten wrote:
>
>> I'm looking for strong opinions on whether we should or shouldn't
>> deprecate the defined() function for Telly, the next major Puppet release
>> this year.
>>
>> jcbollinger put it quite well in another thread:
>>
>> "Use of the "defined" function introduces a parse-order dependency, and
>> the additional work you need to do to ensure that that dependency is always
>> fulfilled overcomes any simplicity advantage that might otherwise exist."
>>
>>
>>
>> --
>> Nigel Kersten
>> Product Manager, Puppet Labs
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> 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.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
I wind up using defined more than I should probably admit. yes it is dangerous/confusing b/c of parse order dependencies, but it is also really useful for a few use cases * static resources in a defined resource type (avoids having to use classes to store all static dependencies) * the big reason I keep on leaning on it is for package dependencies. Often something needs an additional package installed (and it is possible that other modules may have that same package dependency, and I don't want to have to create a new class every time that I need another package (especially for something complicated that may have tons of package dependencies) puppet-apt has a relevant pull request where someone wants to wrap a defined? around python-software-properties for this exact reason https://github.com/puppetlabs/puppet-apt/pull/10 On Thu, Jan 19, 2012 at 9:18 AM, Nigel Kersten wrote: > I'm looking for strong opinions on whether we should or shouldn't > deprecate the defined() function for Telly, the next major Puppet release > this year. > > jcbollinger put it quite well in another thread: > > "Use of the "defined" function introduces a parse-order dependency, and > the additional work you need to do to ensure that that dependency is always > fulfilled overcomes any simplicity advantage that might otherwise exist." > > > > -- > Nigel Kersten > Product Manager, Puppet Labs > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > 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. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
+1 to ditch it. As the other thread said well: use of defined() is only done in badly designed code. Getting rid of it will force people to use better designs. cheers, Walter Heck On Thu, Jan 19, 2012 at 19:19, R.I.Pienaar wrote: > > > - Original Message - >> I'm looking for strong opinions on whether we should or shouldn't >> deprecate the defined() function for Telly, the next major Puppet >> release this year. > > First choice would be to make it reliable, that seems unlikely though > > +1, I'd also make the scope.classes variable private somehow for similar > reasons. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > 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. > -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
- Original Message - > I'm looking for strong opinions on whether we should or shouldn't > deprecate the defined() function for Telly, the next major Puppet > release this year. First choice would be to make it reliable, that seems unlikely though +1, I'd also make the scope.classes variable private somehow for similar reasons. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
[Puppet Users] RFC: Deprecate defined() function for Telly.
I'm looking for strong opinions on whether we should or shouldn't deprecate the defined() function for Telly, the next major Puppet release this year. jcbollinger put it quite well in another thread: "Use of the "defined" function introduces a parse-order dependency, and the additional work you need to do to ensure that that dependency is always fulfilled overcomes any simplicity advantage that might otherwise exist." -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
