main vs. mpf_main: just checking...

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

We are now mostly 3.18 for binaries and for MPF.  We need to begin the journey to 3.21.

For local reasons, our local policy currently replaces the MPF "services/main.cf" file (which is where bundle "main" is defined) with our own small replacement.  The relevant part (currently for MPF<=3.18) looks like:

----------

bundle agent main
# User Defined Service Catalogue
{
  vars:
    any::
      "bundlesequence" slist => {
        "policy_channels",
        "dls_promises"
      };

  methods:
    # Activate your custom policies here
    any::
      "any" usebundle => "$(bundlesequence)";

}

----------

where it is vital that "policy_channels" comes first; and "dls_promises" is the entry point to our local policy.   (We do not use "autorun".  And for various local reasons, any proposal to do adopt this into our extensive, well-established local policy structure would probably meet significant resistance.)

Having read Nick Anderson's blog post https://cfengine.com/blog/2022/renaming-bundle-agent-main-in-mpf/ it seems that the bundle name (in our replacement "services/main.cf" file) must be:

• "main" for client MPF 3.18 (and below)
• "mpf_main" for client MPF 3.21 (and above)
  

My primary question: Is my understanding of this correct?

Secondary question (predicated on the first): to ensure resilient 3.18->3.21 transition, does the following look reasonable?

----------

bundle agent main
{
  methods:
    any::
      "any" usebundle => "mpf_main";
}

bundle agent mpf_main
# User Defined Service Catalogue
{
  vars:
    any::
      "bundlesequence" slist => {
        "policy_channels",

        "dls_promises"
      };

  methods:
    # Activate your custom policies here
    any::
      "any" usebundle => "$(bundlesequence)";

}

----------

The intention here is that our common policy (starting at our "main.cf") can work reliably with potentially different client versions of MPF during this transitional phase.

(BTW, I am also aware that the 3.18->3.21 journey will involve some checking and reviewing of "rxdirs" on some "files:" promises, and I've got Nick's other blog post to hand for that. But that needn't distract us here.)

-- David Lee

[Nick Anderson]

Hi David,

We are now mostly 3.18 for binaries and for MPF. We need to begin the journey to 3.21.

For local reasons, our local policy currently replaces the MPF "services/main.cf" file (which is where bundle "main" is defined) with our own small replacement.

…

Having read Nick Anderson's blog post https://cfengine.com/blog/2022/renaming-bundle-agent-main-in-mpf/ it seems that the bundle name (in our replacement "services/main.cf" file) must be:

• "main" for client MPF 3.18 (and below)
• "mpf_main" for client MPF 3.21 (and above)

My primary question: Is my understanding of this correct?

Yes, that's correct at least from the MPF perspective. In 3.21 and above the default promises.cf lists mpf_main in the bundlesequence instead of main. Note that 3.18 clients are perfectly capable of running 3.21 MPF, so I think simply renaming your bundle from main to mpf_main is the easiest path there.

Secondary question (predicated on the first): to ensure resilient 3.18->3.21 transition, does the following look reasonable?

bundle agent main { methods: any:: "any" usebundle => "mpf_main"; }

bundle agent mpf_main

{ vars: any:: "bundlesequence" slist => { "policy_channels",

"dls_promises" };

methods:

any:: "any" usebundle => "$(bundlesequence)";

}

---

The intention here is that our common policy (starting at our "main.cf") can work reliably with potentially different client versions of MPF during this transitional phase.

Yes, I see no issue with doing it that way. If your following the standard upgrade flow where your running 3.18 binaries with 3.21 MPF this should not be necessary there is nothing special about the binary version that necessitates main vs mpf_main. If however you have some other deployment strategy and you are overlaying this single policy file into a 3.18 policy set running on some 3.18 clients and also overlaying into a 3.21 MPF running on some other clients then I think your suggestion is a good solution.