Hi > Hi Peter, perhaps you started writing your response before reading > my entire message. I suggested a possible solution - behavior > similar to the 'onlyif' option of the exec Type. Look at the docs, > exec only runs the command on the client if the 'onlyif' command, > which also runs on the client, returns an exitcode of zero. > > http://reductivelabs.com/trac/puppet/wiki/TypeReference#id11 > > So, obviously some commands can be executed on the client and impact > what happens next. I'm saying it would be nice to apply such logic > to a block of code instead of an individual exec.
Functions and Variables are executed/evaluated on the master, resources are applied/evaluated on the client. As onlyif is part of a resource it's clear that this command runs on the client, but you shouldn't see it as a command or a function: Your exec example is part of the exec-resource to evaluates its state and is not actually meant as a condition. Your mixings things which don't belong to each another. Maybe you have a look at how puppet internally works [1]. The reason for this problem is that things get evaluated at two different places, which has its reason and is also correct that it works that way. >> And this makes totally sense due to other reasons. I should have added an example here. Maybe have a look at the ext_lookup function as an example why it makes sense, that functions are evaluated on the master. Besides that, maybe a problem we have in this discussion is that if talk about functions we necessary don't mean always the same?! >> So if you use the client-server setup you're restricted to >> that. The >> only information the server can get _from_ the client are >> facts or >> information from an external source, which the client would >> have to feed. >> >> But if you would stay with local execution only I think >> you'll easily >> able to do what you want. > > 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. >> > A wise manager once told me that you should >> > build your systems around the needs of your business >> instead of >> > building your business around the capabilities of your >> systems. >> >> What I could always observe is that people asking for such >> things are >> trying to get their used script thinking behaviour (to call >> it like >> that) into puppet. But one of the main ideas of puppet is >> that it >> changes the way how you look at your infrastructure and how >> you manage >> your infrastructure. So actually: Yes, puppet changes the >> way your doing >> your business. > > What I'm looking for here is nothing extreme. It's very simple. A > set of puppet logic that's only evaluated if a certain condition on > the client is met. What's wrong with that? It sounds very > reasonable to me. On the contrary, having the mindset that > everything should be written as a custom fact, or extension or > whatever, illustrates the point I was trying to make. Sure it > works, but it's a work-around. People get used to the extra effort > required and consider it old-hat when in actuality (again, IMHO) > it's not ideal and in many scenarios is a serious limitation. > > If we use such lines of thinking, then let's just go ahead and get > rid of the conditional operators introduced in 0.24.6. The only > test you need is true or false! Of course I'm kidding here, I love > the ability to use more complex expressions. > > > Anyway, it appears that what I'm looking for may not be possible > today without custom facts. Ok, fine. My next question is, why? > If it's because such functionality just hasn't been added yet, > that's perfectly reasonable. I'll be glad to submit a more detailed > and descriptive feature request. However, if the answer is because > people (most importantly, puppet developers) believe that what I'm > looking for (ability to conditionally process puppet logic based on > the result of a command executed on the client) is unwanted by > users, well I don't believe that's true. I definitely want it and > it's clear others do as well. 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? Besides that I'm not saying that puppet should never do that. But as far as I understood the way puppet works, it has its very own reason and I also think that it's a good way how it is currently. 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 -~----------~----~----~----~------~----~------~--~---
