The bug has been fixed
On 12/18/2010 06:22 PM, Jesse Becker wrote: > On Sat, Dec 18, 2010 at 11:00:23AM -0500, Mark Burgess wrote: >> >> Jesse and Seva, >> >> thank you for pointing out this problem. It was a simple typo (actually >> failure to substitute some old code for new) that resulted in this >> deficiency. Of course this should work. Latest SVN fixes this bug. >> >> BTW - note that the classes alpha,beta etc are somewhat redundant in >> your example, since the real selection is made by $sys.uqhost > > Yeah, I see the redundancy now. This example came from a question from > a co-worker. It was something I cooked up on short notice, and actually > went through a few iterations, trying different ideas where those classes > made more sense. > > Thanks for the note about the bug. I forgot to mention that I'm using > 3.0.5p1. Should I file a report? > >> >> M >> >> On 12/18/2010 12:37 AM, Jesse Becker wrote: >>> So, the snipped below does not work, but I wish that it did. It also >>> isn't limited to package promises either, I can think of cases for file >>> and command promises as well. >>> >>> At a high level, I am trying to define per-host lists, then iterate over >>> those lists, but only on the appropriate host. >>> >>> <-----snip-----> >>> >>> bundle agent testing { >>> >>> vars: >>> any:: 'common' slist => { 'foo', 'quux', 'fubar' }; >>> alpha:: 'pkgs[alpha]' slist => { 'foo', 'bar', 'baz' }; >>> beta:: 'pkgs[beta]' slist => { @{common}, 'yipyip' }; >>> delta:: 'pkgs[delta]' slist => { 'yipyip' }; >>> >>> packages: >>> >>> # only "NY" is needed, since the others are squished into this in >>> # yum.cf >>> centos.!NY:: >>> "${pkgs[${sys.uqhost}]}" >>> handle => "per_host_packages_for_${sys.uqhost}", >>> package_policy => 'add', >>> package_method => yum, >>> ifvarclass => isvariable("pkgs[${sys.uqhost}]"), >>> package_architectures => { 'x86_64' }; >>> } >>> >>> <-----snip-----> >>> >>> >>> What happens is that "${pkgs[${sys.uqhost}]}" is evaluated once, with >>> only "${sys.uqhost}" getting processed, leaving the string as a literal >>> "${pkgs[alpha]}" ). This will, of course, fail when passed to the >>> actual promise in question. >>> >>> I do have a workaround, but it's inelegant. Bascially, flatten the >>> array into multiple slists, and have a separate promise for each one, >>> based on the hostnames. >>> >>> So my question: Is there a concise way to do something like what I've >>> posted above? >>> >>> >> _______________________________________________ >> Help-cfengine mailing list >> Help-cfengine@cfengine.org >> https://cfengine.org/mailman/listinfo/help-cfengine > _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine