On Tuesday, March 31, 2015 at 5:13:07 PM UTC-5, Luan Cestari wrote:
>
> Hi everybody.
>
> I got a question about puppet. I have a case which I would like to run all
> the statements in order and one of them is a custom fact that I created and
> the return is assigned to a variable but I got an error when I do that ("
> Syntax error at '='; expected '}' at ..." ) , the class I'm talking about
> with the line (commented to make it run) is the the following:
>
You cannot chain a variable assignment, and it would make no sense to do so.
>
>
> https://github.com/luan-cestari/lightblue-puppet/blob/bug-fix-lightblue-platform/lightblue-puppet%2344/manifests/java.pp#L51
>
> ( link of the only file related to this issue, but the full repository on
> https://github.com/luan-cestari/lightblue-puppet/tree/bug-fix-lightblue-platform/lightblue-puppet%2344
>
> )
>
> Do you guys have any idea of a possible work around for this case?.
>
The chaining arrows and relational metaparameters are about the order in
which *resources* are *applied*. Neither variable assignments nor custom
fact evaluation is directly involved in that. Furthermore, *all* custom
fact values for a given run are computed before anything is applied --
indeed, before the catalog is built. They describe the target machine's
state before the run.
> I tried many different tricks there (creating even a class) but it didn't
> work.
>
You are having trouble understanding Puppet's operating model, which goes
like this for each run:
1. Plugins are synced
2. The initial state of the target machine is assessed (i.e. all facts
are evaluated)
3. The initial state is submitted to the catalog builder as part of a
catalog request
4. The catalog builder builds and returns a "catalog" describing the
intended state of the target machine
5. Puppet "applies" each resource in the catalog, in an order consistent
with the defined resource relationships, to ensure that the corresponding
physical resource is in the described state.
Fact values are determined at step (2). Variable assignments are performed
at stage (4). Resources are applied at stage (5). To work around that
ordering would require either using different objects or significantly
modifying Puppet itself.
Puppet is not a script engine. You will endure continual frustration as
long as you try to treat it as one.
> I also tried to find someone else with the same problem in google but I
> could with that exactly that message (which I presume it some to do with
> the ordering ( about the anchor that I'm using there, I already removed
> this one but it have the same exception, by the way) )
>
>
If you need to use a datum that is not predictable by either the master or
the target machine before the start of the run, then your alternatives are
1. Write a custom resource type and associated provider. The provider
can perform whatever action you like when it applies resources.
2. Use an Exec to run whatever script or command you need.
One thing that could help me is if I could get the full name of an package
> (including the patch version) , as there is a folder with this name and it
> can change by any update of that package and that class make sure to
> install the package and the major version, but I don't know (and I couldn't
> find) a way to get the full name of the package (my custom fact basically
> use an temporary file that I created during the execution to know the
> version of the package so it could use my custom fact to run 'find' command
> to get the right directory, which wont't exist if the package is not
> installed, so that's why I need the ordering)
>
>
That seems a roundabout way to approach the problem. Some of the more
popular package management systems (e.g. yum, apt) provide a means to check
not only which packages are installed, but also which are *available*. If
such a package manager is relevant to you then you could create a custom
fact that reported the latest available version of the package of
interest. That's the version that will be present after Puppet ensures the
"latest" version installed, supposing that repository changes do not
interfere, or you could ask Puppet to ensure exactly that version.
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/ec77def9-83db-4833-bf17-135f333f9410%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
