>> Both scenarios involve a decision based on output from the client.
>
> Based on output from client, but in totally different ways. When the
> client requests a configuration, it sends all known facts to the server.
> The server then computes the list of resources (evaluating functions
> like "i
On Thursday 29 October 2009 05:00:34 John Philips wrote:
> Perhaps I just need to approach it a different way: create a new type and
> put all my custom logic in there?
I think this may indeed be the direction you could explore. The manifests are
compiled into resources and their parameters on
John Philips wrote:
> But now I'm confused again...
>
> You say that this is possible and may even be implemented soon:
>
> package { 'foobar':
> ensure => installed,
> onlyif => 'test -f /foo/bar',
> }
>
> But something like this is pretty much out-of-the-question?
>
> $foo_exists = clien
> 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
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, t
> > 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,
> I can't speak to the original poster's goal, but actually implementing
> something that lets me declare what the current state is, really does
> require testing what the current state is. Which, presumably, is why the
> exec type already supports "onlyif" and "unless". Extending those to
> other
> I don't want to get deeply into the middle of this (and so will
> leave my contribution to just this e-mail), but there is
> a small point I want to make, that I think Peter touched on, but may
> not have gotten across.
>
> Puppet manifests are declarative, not executable.
>
> The manifests
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 r
> Puppet manifests are declarative, not executable.
This comes up frequently, and seems quite frustrating. People ask
questions, and often are told their questions are wrong, because puppet
is declarative. While it's sometimes correct, sometimes it's wrong. I'm
pretty far from an expert, but I kn
> 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 fe
> > The mailing lists contain
> several postings to the
> > effect of 'custom facts work, just write your own and
> be quiet',
> > which frustrates me.
>
> the main issue behind that is that all the functions are
> evaluated on
> the server and only there.
Hi Peter, perhaps you started writing
Hi
> [...]
>
> It suggests creating a custom fact which indicates if the file exists
> on the client or not. Well, frankly I don't like that idea, for two
> reasons.
>
> 1. I'd have to create a custom fact for every check, which would
> become cumbersome/tedious and is (IMHO) is just a hack/w
13 matches
Mail list logo
