mpf_update_policy_bundle: can this be a list?

[t.d...@servicemusic.org.uk]

CFE-community 3.15.3  (slightly old, I know...)

masterfiles: 3.18.3  (reasonable, I hope)

In "def.json" we've been happily using "mpf_update_policy_bundle" for a year or two.  The local purpose is to drive "policy_channels" (by Vertical SysAdmin; Mike & Aleksey) which requires an additional hook from "update.cf".

In the same way that "policy_channels" is an add-on "blob" of code, so I'm just starting to add another, totally different "blob", which also requires its own hook from "update.cf".

Here's the diff:

------------------------------------------

--- a/masterfiles/def.json
+++ b/masterfiles/def.json
@@ -3,8 +3,8 @@
     "mpf_control_agent_default_repository": [ "any" ]
   },
   "vars" : {
-    "update_inputs" : [ "policy_channels/update_policy_channels.cf" ],
-    "mpf_update_policy_bundle" : "default:update_policy_channels",
+    "update_inputs" : [ "policy_channels/update_policy_channels.cf", "dls_common/update.cf" ],
+    "mpf_update_policy_bundle" : [ "default:update_policy_channels", "default:update_common" ],
     "mpf_update_policy_master_location" : "$(select_masterfiles.master_location)",
     "policy_channels" : {
       "masterfiles_subdir" : "masterfiles"

------------------------------------------

So I've add a new "update.cf" file and adjusted the "mpf_update_policy_bundle" to be a list rather than a scalar, with the intention it should now call two bundles, rather than one.

But it only calls one.  (It so happens it chooses my new "update_common", but it now doesn't call the established "update_policy_channels".)

Debugging with a "-v" confirms that only one bundle is called.  And adding a couple of temporary "reports:" into "update_policy.cf" confirms that its internal "slist" (which sounds like it has the potential to be a multi-element list) "found_matching_user_specified_bundle" is just a single value.

So...

Is it a design feature that "mpf_update_policy_bundle" can only specify a single bundle?  Or perhaps a bug?

(I can probably do a work-around of a single, higher-level bundle which itself then calls both my intended real bundles.  But still...)

-- David Lee

-- Diamond Light Source

[Nick Anderson]

Is it a design feature that "mpf_update_policy_bundle" can only specify a single bundle? Or perhaps a bug?

(I can probably do a work-around of a single, higher-level bundle which itself then calls both my intended real bundles. But still…)

It's by design that it's a single bundle.

You can find the policy in cfe_internal/update/update_policy.cf.

It looks to see if the specified bundle is found and then runs it.

It becomes an slist because you defined it as a list/array. If defined as a list/array I expect that only the last defined bundle will get run because when it looks to make sure the specified bundle exists it uses bundlesmatching() taking the value of def.mpf_update_policy_bundle as the bundle to search for.

# Look for a bundle that matches what the user wants
"found_matching_user_specified_bundle"
  slist => bundlesmatching( "$(def.mpf_update_policy_bundle)" );

If def.mpf_update_policy_bundle is a list, then the value of found_matching_user_specified_bundle will be the result of bundlesmatching() against the last iterated element.

If you want to run multiple bundles for the policy update then you should define just a single bundle which calls the others as methods promises.

If you want to run other bundles as part of the update policy (not specific to policy update) see def.control_common_update_bundlesequence_end.

If you think this should be more explicit, perhaps open a PR to add some additional note to the MPF docs or instrument the policy so that it emits reports if def.mpf_update_policy_bundle is not a string ( see type(), introduced in 3.18.0 ), or perhaps based on length

[Nick Anderson]

Also, there was this blog post about writing a custom update cfbs
module: https://cfengine.com/blog/2022/example-custom-policy-update-cfbs-module/

It might also contain some useful information.

--
Nick Anderson | Doer of Things | (+1) 785-550-1767 | https://northern.tech

[t.d...@servicemusic.org.uk]

Thanks, Nick.  That's most useful.

Yesterday I sketched the idea (that I had suspected I might need, and you confirmed) of "def.json" specifying a "super bundle" calling my functional bundles (our pre-existing "policy_channels" and my new functionality), and it seems to be working fine, calling both of them.  (On test machines I was able flip them back and forth several times (exercising "policy_channels" which now resumes working!) and also seeing it exercise the "before" and "after" of my new functionality.

-- David Lee

[Nick Anderson]

Thanks, Nick. That's most useful.

Yesterday I sketched the idea (that I had suspected I might need, and you confirmed) of "def.json" specifying a "super bundle" calling my functional bundles (our pre-existing "policy_channels" and my new functionality), and it seems to be working fine, calling both of them. (On test machines I was able flip them back and forth several times (exercising "policy_channels" which now resumes working!) and also seeing it exercise the "before" and "after" of my new functionality.

Great, glad you got it working!