HARRIS Jimmy \(AXA-Tech-AU\)
2007-Sep-27 01:20 UTC
How does "case defined(Package["package"])" work?
I''m trying to use a "case defined" statement to configure Munin to automatically create plugin links for packages that are defined by Puppet but the behaviour seems to be unpredictable. I have a similar setup for Samba which works, but the Postfix one doesn''t and I can''t see any difference between them. Can some explain to me how "case defined(Package)" is evaluated? Is it enough just to have a package by that name defined somewhere in Puppet''s configuration (in which case I am seeing a bug) or is there more to the evaluation? Cheers, James ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 27 September 2007, HARRIS Jimmy (AXA-Tech-AU) wrote:> I''m trying to use a "case defined" statement to configure Munin to > automatically create plugin links for packages that are defined by > Puppet but the behaviour seems to be unpredictable. I have a similar > setup for Samba which works, but the Postfix one doesn''t and I can''t see > any difference between them. > > Can some explain to me how "case defined(Package)" is evaluated? Is it > enough just to have a package by that name defined somewhere in Puppet''s > configuration (in which case I am seeing a bug) or is there more to the > evaluation?The recommended syntax would be thus:: if defined(Package["foo"]) { file{"/etc/foo.conf": ... } } else { package{ "foo": ... } } "Be aware though, that - contrary to everything else in puppet - defined-ness of resources is order dependant." From http://reductivelabs.com/trac/puppet/wiki/FunctionReference#defined Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+1E2/Pp1N6Uzh0URAozeAKCFr9tp4EkBg93ky8jkcGMRY3GIbACdGZ/Q fxNIKt/DMz1XVuEXuWkDCYo=kMW7 -----END PGP SIGNATURE-----
On Sep 26, 2007, at 8:20 PM, HARRIS Jimmy ((AXA-Tech-AU)) wrote:> I''m trying to use a "case defined" statement to configure Munin to > automatically create plugin links for packages that are defined by > Puppet but the behaviour seems to be unpredictable. I have a similar > setup for Samba which works, but the Postfix one doesn''t and I > can''t see > any difference between them. > > Can some explain to me how "case defined(Package)" is evaluated? > Is it > enough just to have a package by that name defined somewhere in > Puppet''s > configuration (in which case I am seeing a bug) or is there more to > the > evaluation?As David mentioned, it''s order-dependent. A much better way to solve this kind of problem is to create a wrapper definition, something like: define munin-package($ensure) { package { $name: ensure => $ensure } file { "/path/to/link": ensure => symlink, target => "/path/to/ file" } } This way you don''t have to do anything semi-magical, which the ''defined'' thing will always be, unfortunately. -- The Internet, of course, is more than just a place to find pictures of people having sex with dogs. -- Time Magazine, 3 July 1995 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
HARRIS Jimmy \(AXA-Tech-AU\)
2007-Sep-27 22:26 UTC
Re: How does "case defined(Package["package"])" work?
> > Can some explain to me how "case defined(Package)" is evaluated? Isit> > enough just to have a package by that name defined somewhere inPuppet''s> > configuration (in which case I am seeing a bug) or is there more tothe> > evaluation? > > The recommended syntax would be thus:: > > if defined(Package["foo"]) { > file{"/etc/foo.conf": ... } > } else { > package{ "foo": ... } > } > > "Be aware though, that - contrary to everything else in puppet -defined-> ness > of resources is order dependant." From > http://reductivelabs.com/trac/puppet/wiki/FunctionReference#definedThanks David, the ordering dependency explains why it seems a little unpredictable and small changes can have big effects. Are there any plans to fix/change this (or is it a difficult problem to solve)? If not, I''ll have to take another look at the order in which my configuration is being evaluated. James ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
HARRIS Jimmy \(AXA-Tech-AU\)
2007-Sep-27 22:30 UTC
Re: How does "case defined(Package["package"])" work?
> Are there any plans to fix/change this (or is it a difficult problemto> solve)? If not, I''ll have to take another look at the order in whichmy> configuration is being evaluated.Sorry, just saw Luke''s reply and that does look like a better way of solving the problem. James [Here it is for reference] As David mentioned, it''s order-dependent. A much better way to solve this kind of problem is to create a wrapper definition, something like: define munin-package($ensure) { package { $name: ensure => $ensure } file { "/path/to/link": ensure => symlink, target => "/path/to/ file" } } This way you don''t have to do anything semi-magical, which the ''defined'' thing will always be, unfortunately. ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
On Sep 27, 2007, at 5:26 PM, HARRIS Jimmy ((AXA-Tech-AU)) wrote:> Are there any plans to fix/change this (or is it a difficult > problem to > solve)? If not, I''ll have to take another look at the order in > which my > configuration is being evaluated.It''s a problem that''s either difficult or (I think) impossible to solve. You''re essentially testing whether a part of your resource has been evaluated yet. The only real way to do that without ordering problems is to lazy- evaluate conditionals, which, AFAICT, is catestrophically difficult. Fortunately, there are better ways, so... -- The people who are regarded as moral luminaries are those who forego ordinary pleasures themselves and find compensation in interfering with the pleasures of others. -- Bertrand Russell --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
HARRIS Jimmy \(AXA-Tech-AU\)
2007-Sep-27 23:09 UTC
Re: How does "case defined(Package["package"])" work?
> As David mentioned, it''s order-dependent. > > A much better way to solve this kind of problem is to create a > wrapper definition, something like: > > define munin-package($ensure) { > package { $name: ensure => $ensure } > file { "/path/to/link": ensure => symlink, target => "/path/to/ > file" } > } > > This way you don''t have to do anything semi-magical, which the > ''defined'' thing will always be, unfortunately.I''ve just been thinking this through a bit more and I don''t think it''s actually any use in the situation I''m thinking of. What I am trying to do is create a munin-node definition that is aware of other modules and graphs them only if they are defined elsewhere for that server. i.e. The munin-node knows that if Postfix/Samba/Apache is defined for a server, then it should automatically create the links to the appropriate plugins. If not, it will make sure that they don''t exist so Munin doesn''t end up with blank graphs. Yes, I could put these links in the Postfix/Samba/Apache definitions, but that''s starting to get messy and not all our servers have Munin on them anyway. Other than using Puppet''s "case defined" evaluation or writing an external script, I can''t think of a way to solve this. James ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
On Sep 27, 2007, at 6:09 PM, HARRIS Jimmy ((AXA-Tech-AU)) wrote:> I''ve just been thinking this through a bit more and I don''t think it''s > actually any use in the situation I''m thinking of. > > What I am trying to do is create a munin-node definition that is aware > of other modules and graphs them only if they are defined elsewhere > for > that server. i.e. The munin-node knows that if Postfix/Samba/ > Apache is > defined for a server, then it should automatically create the links to > the appropriate plugins. If not, it will make sure that they don''t > exist so Munin doesn''t end up with blank graphs.The point of my recommendation still stands -- find a way to put the link definition in the same place as you''re putting the code that results in the link being required. I don''t know enough about why you need the link to know what triggers it, but you should be able to do something to abstract this out some, I would think (but of course I don''t know). -- You''ve achieved success in your field when you don''t know whether what you''re doing is work or play. -- Warren Beatty --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
HARRIS Jimmy \(AXA-Tech-AU\)
2007-Sep-27 23:45 UTC
Re: How does "case defined(Package["package"])" work?
> > What I am trying to do is create a munin-node definition that isaware> > of other modules and graphs them only if they are defined elsewhere > > for > > that server. i.e. The munin-node knows that if Postfix/Samba/ > > Apache is > > defined for a server, then it should automatically create the linksto> > the appropriate plugins. If not, it will make sure that they don''t > > exist so Munin doesn''t end up with blank graphs. > > The point of my recommendation still stands -- find a way to put the > link definition in the same place as you''re putting the code that > results in the link being required. > > I don''t know enough about why you need the link to know what triggers > it, but you should be able to do something to abstract this out some, > I would think (but of course I don''t know).I understand what you''re saying, but the only place where that is defined is in my sites.pp file and it will vary from host to host. One might have Postfix included and not Munin (no link), one might have Munin and not Postfix (no link) and one might have both (link). For any host, there are two possible conditions that I want do deal with: - Iff Postix AND Munin-node are defined for that host, then create the link. - If Munin-node AND NOT Postfix are defined for that host, remove the link if it exists. The problem is that (as far as I am aware) neither module can be aware if the other one is included in a particular host''s configuration without using the "case defined" statement or resorting to a hack like checking for a flag or configuration file or similar. Please correct me if I''m wrong. James ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
ADNET Ghislain
2007-Sep-28 05:13 UTC
Re: How does "case defined(Package["package"])" work?
> For any host, there are two possible conditions that I want do deal > with: > > - Iff Postix AND Munin-node are defined for that host, then create the > link. > - If Munin-node AND NOT Postfix are defined for that host, remove the > link if it exists. >i have the exact same issue with awstats and the packages: - awstats alone do nothing - awstats and apache do stats for websites defined - awstats and ftp do ftp stats - awstats and email do email stats but awstats is not required on all node, all node do not have ftp/mail/apache installed. I do not found a clean way to manage this dependency in puppet (ie in the ftp module add an awstats config if awstats is here...) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Sep 28, 2007, at 12:13 AM, ADNET Ghislain wrote:> i have the exact same issue with awstats and the packages: > > - awstats alone do nothing > - awstats and apache do stats for websites defined > - awstats and ftp do ftp stats > - awstats and email do email stats > > but awstats is not required on all node, all node do not have ftp/ > mail/apache installed. I do not found a clean way to manage this > dependency in puppet (ie in the ftp module add an awstats config if > awstats is here...)Ah, I see what you''re talking about now. Some form of the following should work for you, then: class one { @notify { "doing one": tag => testing } } class two { Notify <| tag == testing |> } include one, two Just tag the awstats/munin/whatever-related resources, and make them virtual. Then in your awstats et al classes, collect those resources based on tags. Note that although this was part of my plan when creating virtual resources, I expect no one is doing this, and as a result it hasn''t been well-tested. In particular, it doesn''t work with arrays (so you can only have the one tag), it doesn''t appear to be using autogenerated tags (e.g., the class names), and I''m sure you''ll find plenty of other problems. But at least this should be a start. And please, if you get this working, come up with some sort of clever name for it and document your work on the wiki. :) -- I cannot and will not cut my conscience to fit this year''s fashions. -- Lillian Hellman --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
ADNET Ghislain
2007-Oct-12 04:43 UTC
Re: How does "case defined(Package["package"])" work?
> Ah, I see what you''re talking about now. > > Some form of the following should work for you, then: > > class one { > @notify { "doing one": tag => testing } > } > > class two { > Notify <| tag == testing |> > } > include one, two > > Just tag the awstats/munin/whatever-related resources, and make them > virtual. Then in your awstats et al classes, collect those resources > based on tags. > >does the class order is important here ? I mean if i have several classes that interact like this does the include order has any influnces on the behavior ? and does it works with defined types now ? -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Oct 11, 2007, at 11:43 PM, ADNET Ghislain wrote:> does the class order is important here ? I mean if i have several > classes that interact like this does the include order has any > influnces on the behavior ? > and does it works with defined types now ?File order should not matter, and yes, it should work with defined types, at least for virtual stuff. You still can''t collect defined types from the db. -- I have lost friends, some by death... others through sheer inability to cross the street. -- Virginia Woolf --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com