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
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
