Hi,
Hopefully this attaches itself to the correct thread, no email in my
inbox to respond to for this one. ¯\_(ツ)_/¯
Can you provide a completely stand-alone policy so that we can easily run and re-produce the problem you have?
Proceeding only with my internal parser :)….
Regarding "only works if the data and filter classes are in the same bundle"
, I suspect that you are just seeing class scope at work. In the documentation, Classes and Decisions in Language Concepts of the Reference manual has a section on Class scope which talks about this a bit. It looks like you are using classes that are defined with a bundle scope (only visible within that bundle) and when you call your child_bundle you did not have it inherit the classes, so inside of child_bundle, any bundle scoped classes that were defined in parent_bundle won't be visible.
bundle agent __main__ { methods: "parent"; } bundle agent parent { classes: "my_bundle_scoped_class_defined_in_parent"; methods: "Write our child into our will" usebundle => child, inherit => "true"; "Step children get the shaft by default" usebundle => step_child; } bundle agent child { reports: "$(this.bundle): I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will." if => "my_bundle_scoped_class_defined_in_parent"; "$(this.bundle): I wasn't written into the will, at least I am not red-headed." unless => "my_bundle_scoped_class_defined_in_parent"; } bundle agent step_child { reports: "$(this.bundle): I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will." if => "my_bundle_scoped_class_defined_in_parent"; "$(this.bundle): I wasn't written into the will, at least I am not red-headed." unless => "my_bundle_scoped_class_defined_in_parent"; }
R: child: I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will. R: step_child: I wasn't written into the will, at least I am not red-headed.
Regarding "i want to use the data container as a somewhat "global" variable without repeating it"
, I don't think that you have to repeat the data container, you can pass it whole like you do, or pass it's name. Either way, you don't get a variable registered in the state (see --show-evaluated-vars
).
bundle agent __main__ { vars: "my_data" data => '{ "data": "here" }'; methods: "Pass data container" usebundle => example_1( @(my_data) ); "Pass NAME of data container" usebundle => example_2( "$(this.namespace):$(this.bundle).my_data" ); } bundle agent example_1(my_data) { vars: "my_data_$(this.bundle)" data => '{ "bundle": "$(this.bundle)" }'; reports: "$(this.bundle):$(with)" with => storejson( @(my_data) ); } bundle agent example_2(my_data) { vars: "my_data_$(this.bundle)" data => '{ "bundle": "$(this.bundle)" }'; reports: "$(this.bundle):$(with)" with => storejson( $(my_data) ); }
# cf-agent --no-lock --log-level info --show-evaluated-vars=my_data --file /tmp/example.cf R: example_1:{ "data": "here" } R: example_2:{ "data": "here" } Variable name Variable value Meta tags Comment default:example_1.my_data_example_1 {"bundle":"example_1"} source=promise default:example_2.my_data_example_2 {"bundle":"example_2"} source=promise default:main.my_data {"data":"here"} source=promise
Hope this helps …
Xander Cage <christia...@itsv.at> writes:
i forgot to mention that the above shows hat the "filter classes" in the classesfiltercsv function not "filtering" when used in various child bundles if the definition of the datacontainer or the call to the classfiltercsv function is not present in the bundle.
Reading the policy …, you are using classfiltercsv()
inside of bundle agent parent_bundle
. Running with your data set I get no data container defined, for example:
# cf-agent --no-lock --log-level info --show-evaluated-vars=parent_bundle --file /tmp/example.cf R: check_user reached: $(user) R: create_users reached: $(user) R: parent bundle: $(user) Variable name Variable value Meta tags Comment default:parent_bundle.data_file /tmp/my.csv source=promise default:parent_bundle.keys source=promise default:parent_bundle.keys_unsorted source=promise default:parent_bundle.my_data [] source=promise
This is because none of the class expressions in your first (zeroth) column evaluate to true on my system in that bundle. So, I added a row that would (any,nickanderson,Nick Anderson,neither-us-nor-them,ssh-bs
) and I modified the policy to point to the path I am using for the CSV (/tmp/my.csv
)
ClassExpression,uid,name,group,ssh_key weirdos,mscott,Michael Scott,pathetic,ssh-someSupERsecretKey287483438dsdjhdsdsdjahhsgdsg weirdos,jkras,John Krasinski,pathetic,ssh-someSupERsecretKey287483438dsdjhdsdsdjahhsgdsg twats,tflen,Toby Flenderson,tedious,ssh-someSupERsecretKey287483438dsdjhdsdsdjahhsgdsg zombie,wimm,,dbaldap,
ssh-someSupERsecretKey287483438dsdjhdsdsdjahhsgdsg any,nickanderson,Nick Anderson,neither-us-nor-them,ssh-bs
bundle agent parent_bundle { vars: "data_file" string => "/tmp/my.csv"; "my_data" data => classfiltercsv( $(data_file), "true", 0);
With that change, the rows with class expressions that evaluate to true become part of the data container that result from parsing.
# cf-agent --no-lock --log-level info --show-evaluated-vars=parent_bundle --file /tmp/example.cf R: check_user reached: nickanderson R: create_users reached: nickanderson R: parent bundle: nickanderson Variable name Variable value Meta tags Comment default:parent_bundle.data_file /tmp/my.csv source=promise default:parent_bundle.keys {"0"} source=promise default:parent_bundle.keys_unsorted {"0"} source=promise default:parent_bundle.my_data [{"group":"neither-us-nor-them","name":"Nick Anderson","ssh_key":"ssh-bs","uid":"nickanderson"}] source=promise default:parent_bundle.user nickanderson source=promise
Reading the policy further …., some bundles (bundle agent check_user
, and bundle agent create_user_new
) are promised as methods. Inside these bundles there are some bundle scope classes defined and some variables are created by pulling the data off of the previously defined data container that is passed in to the bundle as an argument.
whats the deal if i have to define all filtering classes in the parent bundle? seems useless to me. this function is at least somewhat inconvenient , or i am doing something completely wrong. any insights?
Yes, sorry to say, I think you have a completely different expectation of what the behavior should be than what it provides.
To me, it looks like you expect classfiltercsv()
to filter your data set when you access the data set. That might be a nifty function in it's own right, but that is not how classfiltercsv()
behaves. classfiltercsv()
filters the data as it is read in based on the context at that point in time.
So, if you want one data set of the rows that match weirdos and twats and another data set consisting of the rows that match zombie as I believe your example policy illustrates you would need to make 2 calls to classfiltercsv()
.