Ohai chefs,
I have an interesting scenario where I need to dynamically update ohai
attributes after an action is performed as part of an earlier cookbook
during a chef-client run.
Scenario:
- package update runs at start of chef-client run.
- this package update in turn causes the server platform_version.to_f to
jump a point release
- This platform_version attribute is used to determine a config (the
release jump causes configs to change)
I’ve tried an ohai reload as part of the package update recipe, but both
testing and documentation both indicate this won’t work unless I use some
sort of lazy or delayed processing to determine this attribute.
As it stands, the package update runs, chef-client completes run as if it
was on the older platform_version, and then it updates the other configs 30
minutes later during the next chef-client run.
I understand that these attributes are dialed in during the compilation
phase.
My question is: how do I ‘reset’ the attributes within the later cookbook
outside of the ‘lazy’ parameter in a resource block? Do I need to use some
hackery within a ruby_block to reset an if/else block?
psuedo code:
variable = nil
boolean = false
if #{platform_version.to_f} >= x.y
variable = something
boolean = true
end
if boolean:
file 'somefile’
end
end
Thanks for any information!
You can force the packages to install at compile-time and then notify
ohai to reload also at compile-time to pick up the changes.
Note that this may cause a bit of a race to compile_time since any
prereqs (like apt-get update) will also need to move to compile-time.
It does 'fix' the platform_version problem as soon as possible in the
chef run, though, which is probably what you want to do since then all
the compile-time ruby code which comes later can inspect
platform_version and get the 'right' answer without you having to move
all your logic into ruby_blocks or lazy'ing everything -- which is
likely a much worse yak shave of a converge-time arms race.
On 08/28/2015 10:56 AM, Mathew Crane wrote:
Ohai chefs,
I have an interesting scenario where I need to dynamically update ohai
attributes after an action is performed as part of an earlier cookbook
during a chef-client run.
Scenario:
- package update runs at start of chef-client run.
- this package update in turn causes the server platform_version.to_f
to jump a point release
- This platform_version attribute is used to determine a config (the
release jump causes configs to change)
I've tried an ohai reload as part of the package update recipe, but
both testing and documentation both indicate this won't work unless I
use some sort of lazy or delayed processing to determine this attribute.
As it stands, the package update runs, chef-client completes run as if
it was on the older platform_version, and then it updates the other
configs 30 minutes later during the next chef-client run.
I understand that these attributes are dialed in during the
compilation phase.
My question is: how do I 'reset' the attributes within the later
cookbook outside of the 'lazy' parameter in a resource block? Do I
need to use some hackery within a ruby_block to reset an if/else block?
psuedo code:
variable = nil
boolean = false
if #{platform_version.to_f} >= x.y
variable = something
boolean = true
end
if boolean:
file 'somefile'
end
end
Thanks for any information!
The root of the problem is that a chef-client run has one massive “top
level” compile-and-converge cycle.
Chef doesn’t “move on to the next cookbook”, or even recipe, it moves onto
the next resource.
Until we have a first-class way to have multiple compile/converge cycles
during a chef-client run, I’d say the sanest thing to do in this specific
case would be to rely on multiple chef-client runs.
That, or re-baseline your starting machine state to the new point release.
Playing the converge-time arms race game destroys cookbook reuse by forcing
you to modify all your code, creates massive amounts of confusion, and
completely breaks the notifications and subscriptions.
-s