Trigger re-reading of facts?

[Jason Price]

Problem: Puppet pushes two files, and two services.  One service (redis) reads one of the files (a lua script), and spits out a sha1sum.  However, it somehow transforms the file before it produces the sha1sum, so there's no way to know what the sum will be, before the reading.

File two (read by service two) must know what the sha1sum if the first file is.

Semi-obvious solution: make external fact to read in the file, and produce the sha1sum as a fact readable by puppet.  Use said fact in the template for file2, and you're done.

However, the facts are generated before any files are changed via puppet.  And I hate having to run puppet twice to converge on a correct setup.

Is there a way for the manifest to do:

file { 'script.lua' :

  ensure => 'present',
  ...

  source => 'puppet:///modules/foo/script.lua'
}
->

INSERT MAGIC REREAD FACTS BLOCK
->

file { 'file2' :

  ensure => 'present',

  ...

  template => template('foo/file2.erb')
}

?

Thanks for any help.
Jason

[José Luis Ledesma]

It would be very interesting to read other people opinion.

From my point of view I currently only see a couple of solutions, and I don't like any of them.

The first one is what you have said, a custom fact and run the puppet twice.

The second one is uglier yet, use a exec to set the sha1sum inside the template.

Regards,

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAChvjRD%3DTtCdgBGqp2en0OJsBWyfJ0xQhrf6UcrPXTUumMbDew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Thursday, March 27, 2014 10:40:19 PM UTC-5, Jason Price wrote:

Problem: Puppet pushes two files, and two services.  One service (redis) reads one of the files (a lua script), and spits out a sha1sum.  However, it somehow transforms the file before it produces the sha1sum, so there's no way to know what the sum will be, before the reading.

File two (read by service two) must know what the sha1sum if the first file is.

Semi-obvious solution: make external fact to read in the file, and produce the sha1sum as a fact readable by puppet.  Use said fact in the template for file2, and you're done.

However, the facts are generated before any files are changed via puppet.  And I hate having to run puppet twice to converge on a correct setup.

Is there a way for the manifest to do:

file { 'script.lua' :

  ensure => 'present',
  ...

  source => 'puppet:///modules/foo/script.lua'
}

Note: be sure to use replace => false on that file if it is going to be modified after installation outside of Puppet's scope.  Be aware, however, that that is a double-edged sword: you will not clobber changes, but you also will not be able to push out updates.

 

->

INSERT MAGIC REREAD FACTS BLOCK
->

file { 'file2' :

  ensure => 'present',

  ...

  template => template('foo/file2.erb')
}

?

Simple answer: no.  All facts for any given run are evaluated before the client makes its catalog request, and included in the request.  It is a deep-rooted Puppet principle that none of these change during the course of catalog compilation, which includes evaluating all templates.  Moreover, the catalog is fully compiled (again, including evaluation of all templates) before any of it is applied, so "MAGIC REREAD FACTS BLOCK" could not anyway obtain the data you want at an appropriate time.

Both of the approaches Jose suggested are viable.  I don't immediately see any others for the given definition of the problem, but there might be better options available if you take a step back and look at the bigger picture.  For example, could you put both files in a custom package, using redis during the package build process to produce the needed version of file1 and its checksum?  Other possibilities might present themselves if you give us a better understanding of the nature and role of the files involved.


John