Hi >>> If it's so easy, please provide an example >> solution. And if your >>> example consists of disparate facts to determine if >> specific files >>> exist, please don't bother because that's specifically >> what I said I >>> wasn't looking for :-) >> simply use puppet as a standalone tool, then your only on one host >> and everything gets evaluated in the same place. The restriction >> (in your terms) that this can only be satisfied using facts is only >> due to the reason that we're in a client/server relation and not >> everything gets evaluated on the same host. > > Peter, sorry if it appears that I'm using you as a target, but you > just put a big bullseye on yourself :-) If I understand correctly, > you suggest running puppet individually on every single host and > having the hosts query themselves, i.e. no central puppetmaster? So, > if I wanted to make a global change, I'd have to somehow manually > distribute new puppet manifests out to every single host. That > totally defeats what I see as the purpose of puppet - centralized > management of hosts.
I have been simply arguing that you get your current idea (apply a 'local' onlyif to a whole block) with this kind of setup. Nothing more. And I tried to outline why it will only work with the standalone setup and why not with the client/master setup. >> it's mainly due to the reason how puppet works. the client sends >> its facts to the master, this one evaluates the manifests with this >> information and executes the functions and sends down the compiled >> catalog to the client. This one, only applies the catalog and does >> the necessary changes to fit into the described state. As mentioned >> above to onlyif is just part of an exec resource to determine its >> state. >> >> There are many more reasons why this is a good architecture and why >> your problem can be still achieved in the puppet way. Which means >> not in a script style, but in a declarative manner, which is what's >> the basic idea of puppet. >> >> I hope I could explain things more clear. So the question is now >> how would you like to fit your simple idea into this setup and way >> how puppet works? > > As I said earlier, if it involves creating a custom fact for every > test, then I'm not interested. If there's some other way, then by > all means please share. > > > > Anyway, I was about to go into a long diatrabe of reasons as to why > my request has merit along with numerous examples. Then I noticed > this thread from January 2008: > > http://markmail.org/message/2nrbjwjz3vcuiacl > > Nigel from Google asked for the same thing I'm asking for, and Luke > agreed it should be made available. To quote one of Luke's > responses, "I guess I should actually get this done". That's > justification enough for me! :-) well imho what is talked about in this thread is an onlyif parameter for a resource, so unless/onlyif as a metaparameter. Right? BUT this won't be something like: if File.exist?('/foo/bar') { package{'foobar': ensure => present } } this will be like: package{'foobar': ensure => installed, onlyif => 'test -f /foo/bar', } but your were suggesting something like: --- quote --- In pseudo-code: if file_exists("/opt/orange_app") { # file exists, load the module include orange } --- /quote --- or as you stated you like to have: "But instead of the 'onlyif' applying to a single exec, I'd like it to to apply to an entire block of code in my puppet manifest." Which is something FUNDAMENTAL different to the onlyif metaparameter and which I was trying to argue is evaluated on a different level, hence it isn't that easy and won't work as you think so. I have never been and I never intended to argue against an onlyif metaparameter for resources. I simply tried to outline what is the difference between an onlyif parameter and a statement in the code, which you prefered over an onlyif parameter. I somehow think I failed with that. Besides that, if we are talking about onlyif/unless as a metaparameter: There have even been recently some work to provide unless as a metaparameter. See "possible #651 patch" thread on the puppet-dev list and maybe also have a look at bug #651. > I'll file a formal feature request in the ticketing system and look > forward to seeing it in a future release. Pretty please? :-) if you really need to get things implemented you are currently missing, you can always get in touch with reductivelabs and I assume they'll happily work things out with you. cheers pete --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
