On Thursday, November 14, 2013 3:06:05 AM UTC-6, ulrich igor ngouagna
kouete wrote:
>
> Hi,
> thanks for reacting.
>
> To describe more what I want to do:
>
> I have a web API and I want to make some REST requests to it, and verify
> the response satus or body to make sure the request succeeded. With "curl"
> it gives this:
>
> exec{"add a cluster ${clusterName}":
> command => "curl -u
> ${$::clouderapuppet::cm::server::params::cmUsername}:${$::clouderapuppet::cm::server::params::cmUsername}
>
> -X POST -H \"Content-Type:application/json\" '
> http://localhost:7180/api/v4/clusters' -d
> '{\"items\":[{\"name\":\"${clusterName}\",
> \"version\":\"${clusterVersion}\"}]}'"
> }
>
> See how it is long and annoying? (hahah ;) ). And imagine I have to POST a
> huge JSON doc, the code will be unreadable!
>
> Do you tell me I can do that with hiera or generate() function?
>
> I'll explore those paths now, but feel free to continue the discussion :)
>
On master/agent setups there is an exceedingly important distinction
between doing this sort of thing (or anything, really) via a resource and
doing it via a function: resources are applied on the client, after catalog
compilation is complete, whereas functions are evaluated on the master,
during catalog compilation. Therefore, if you want to collect data to
inform catalog compilation or catalog contents then it must be done via a
function (or earlier, via a fact), but if you want to manage or test some
aspect of the target node then you must use a resource, or perhaps a fact.
When you described your problem as wanting to issue a web request "from a
manifest file", I supposed you had the former case, as manifests are a
detail of catalog compilation, not directly relevant to clients. Inasmuch
as your example directs its web request to localhost, however, it appears
that you may instead be trying to test details of the configuration of the
target node. If that's so then a function (including hiera) will not do
the job you require.
If you want to know about the behavior of web requests prior to application
of any resources, and especially if you want to use that information to
influence the contents of the node's catalog, then you need to write a
custom fact. Alternatively, if you want to issue a web request in the
middle of catalog *application*, and possibly to condition whether certain
other declared resources are applied on the result of the request, then you
need a resource.
I have no specific experience with the mmorsi-web_request module, and its
description on the Forge doesn't provide much detail. It sounds like it is
supposed to support behavior similar to what you may be after, however.
Certainly, it claims to be able to issue POST requests, though I see no
particular evidence that it supports arbitrary request bodies or allows
arbitrary headers to be provided. If it does not have such facilities then
you could consider submitting a feature request or else modifying the
module yourself to add the feature you need.
On the other hand, an Exec is certainly capable of doing the job in
combination with curl, wget, or similar on the target system. You appear
to have that figured out already. Your concern about the complexity of the
Puppet declaration you must use in that case is well-founded, but inasmuch
as in that regard you seem more worried about the content body than about
anything else, you will have that issue even with mmorsi-web_request or any
similar module. I would suggest handling it by generating the content body
via an external ERB template, using Puppet's built-in template() function.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b66ce8ac-ade6-4e99-9d51-a9305a979d47%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
