There is a known bugwhere getindicesis unable to get the index of a dynamically generated array until the next pass. This comes up from time to time so I thought I would post an example using a pattern shared on the CFEngine help mailing list. The policy below shows 3 working examples. They are mostly similar, example0 shows the simplest workaround, example1 and example2 in addition show ways to suppress the “Duplicate selection of value for variable” messages.
Changelogs are just as important as the most important meal of the day. OK so I don’t always eat breakfast, but I do make an effort to read changelogs. CFEngine 3.4.2was released today. What I found interesting was that the default masterfiles policy has been updated. body executor control now calls $(sys.workdir)/inputs/update.cf instead of failsafe.cf. And $(sys.workdir)/failsafe/failsafe.cf (which was new as of 3.4.0) is gone. I think its a good change.
Sometimes you want to know what value zenoss has for something. The numbers sent in alerts seem to be the value that zenoss has, but the graphs are usually formatted to make more sense. 1394606080 might come in an alert, but on the graph it would show as 1.3 or 1.4G. It can cause some slight confusion when other people expect 90% of 1.4G instead of 90% of 1394606080 to be an alert threshold.
Over the past several months2 years (since 3.1.2 release, wow time flys when your having fun. I checked and 3.1.2 was releasedon Dec 9th 2010.) I have seenafewquestionsregarding how the default CFEngine policy update works, and more specifically how cf_promises_validated plays into the update process. This is my stab at describing the history and behaviour. I welcome any corrections. The default failsafe.cf update policy is simple in nature. (We could probably debate what is simpleor complex, but I am comfortable with the label in this case.
CFEngine defines a classes for decision making during runs. Many of these hard classes you can see by running cf-promises -v. That wont show you all the other classes that are raised during a policy run. You could run something like this to see what classes are raised during execution. But that isn’t really a clear picture under normal operation. You can use the allclassesreport in body agent control to write out a list of classes defined during execution in /var/cfengine/state/allclasses.
Methods type promises are powerful abstraction tools in CFEngine 3. Methods allow you to activate bundles (optionally parametrized) from other bundles. This allows encapsulation of knowledge and lends itself to re-usability. I just want to share an example of calling bundles dynamically. It’s a contrived example, but I thought it was neat so here it is. <div class="gist-meta"> <a href="https://gist.github.com/raw/3901453/0b683269921c056b4e821dd2c63ca6b622122e26/output" style="float:right;">view raw</a> <a href="https://gist.github.com/3901453#file_output" style="float:right;margin-right:10px;color:#666">output</a> <a href="https://gist.github.com/3901453">This Gist</a> is brought to you using <a href="http://en.
Are you going to LinuxCon/CloudOpen 2012? I am, and I think I have settled on my picks (at least until I look at the schedule again, lots of great options). Special thanks to CFEngine for sponsering me! Here are my picks for the minute. Building the Open Cloud – Mark Hinkle, Citrix{#9046eff8494ef50f48da95349905592e} The OpenNebula Cloud Platform for Data Center Virtualization – Carlos Martin, OpenNebula{#5561a1f9b3d063dcca4b7abdc5dbc44b} Cloning SysAdmins with the Cloud and Juju – Clint Byrum, Canonical{#82e5d5410f32e11be9bd9bddf2b81570} A Collaborative Approach to Managing Linux Configurations – Diego Zamboni, CFEngine{#da5dea5f6f017f925dac66eec964f13f} Building FOSS Clouds – Joe Brockmeier, Citrix{#c28982d2a4f52cbfbb4000ce030a1771} Automation and DevOps Best Practices – Rob Hirschfeld, Dell{#f0cd279b854c642d12e7d531c68c53f0} Scaling Configuration Management Across Data Center and Cloud – Mark Burgess, CFEngine{#e9936ee3a0369080a61b61f5eb9a88d4} Editing with vi: Advanced Topics, Part I – Aleksey Tsaloikhin, Vertical Sysadmin, Inc.
I was inspired by William Orr’s svn commit hook and looked up the magic needed to flesh out the git pre-commit hook I submitted to the Design Center a while back. Now the index is checked out to its own temporary directory and cf-promises validates promises.cf and failsafe.cf before allowing the commit to proceed. Now you won’t get syntax errors if you have forgotten to add a new policy file to the index but its already included in your body common control inputs list.
I updated the CFEngine 3 by example vagrant project so that /var/cfengine/masterfiles is a git clone (kept in sync with VCS::vcs_mirror) of the generated bare repository from the seed files. I found during a presentation that it would just be easier to have everyone start of with the typical workflow instead of going through the process of getting there. I hope it makes it easier for people to get a working test env up in a few minutes.