Are defaults: just for strings?

[eb4x]

From the documentation

Defaults promises are related to variables. If a variable or parameter in a promise bundle is undefined, or its value is defined to be invalid, a default value can be promised instead.

And in some examples slist is put in defaults:, though not used in vars: under a guard.

Small example

bundle agent __main__
{
  vars:
    use_overrides::
      "mystring" string => "this is the override string";
      "mylist" slist => { "this", "is", "the", "override", "list" };

  defaults:
    "mystring" string => "this is my string";
    "mylist"  slist => { "this", "is", "my", "list" };

  classes:
    "use_overrides" expression => "true";

  reports:
    "Hello!";
    "mystring: $(mystring)";
    "mylist: $(mylist)";
}

And the unexpected result;

# CFEngine Core 3.24.3
cf-agent -Kf ./test.cf
R: Hello!
R: mystring: this is the override string
R: mylist: this
R: mylist: is
R: mylist: my
R: mylist: list

I've worked around this, but I was starting to get in the groove with a defaults/overrides pattern.

[larsewi]

This looks like a bug. I created a ticket in our bug tracker to follow up on this (see CFE-4643).

Thanks for reporting it @eb4x

[nickanderson]

Humm, I don't recall ever having used defaults promises with slists. slists don't align well with if_match_regex. Which element would the regex match? would it iterate and try to match each element or would it join and match, would it short circut on first match?

I haven't searched for it but I doubt we would find much if any prior art using defaults with slists. I suspect that slist being shown in the example is perhaps a bug.

Beyond that, in general I avoid the use of defaults. I find them quite difficult to reason about and with. Rather than use defaults from within policy, I generally reccomend leveraging Augments. There you can set a value for a variable, and then in policy you can choose to keep that variable or override it. You will find many cases of if => isvariable() in def.cf in the MPF that use this methodology.

[eb4x]

I'm new at cfengine, so I wouldn't know the ins and outs, and how or even if if_match_regex should be available if it's not a string object.

My understanding from the documentation as written is that if you can't find something defined in the vars: section, see if there's something to use from the defaults: section. A pattern I rely heavily on in ansible, so when I first saw it I thought I'd struck gold.

It got tedious writing guards to end up with the correct value during the calculations of which you should use.

!one.!two.!three.!four::
  "mystring" string => "some default";
one::
  "mystring" string => "it's one!";
two::
...

I still have a hard time understanding augments, when I read the documentation it's just too abstract for me to wrap my head around. Though it looks like a superpower if I could ever figure out how to use it properly.

Right now I only dump this to /var/cfengine/masterfiles/def.json so I don't have to modify the MPF.

{
    "augments": [
        "$(sys.workdir)/atoms.json"
    ],
    "inputs": [
        "services/myexample.cf"
    ],
    "vars": {
        "control_common_bundlesequence_end": [
            "myexample"
        ]
    }
}

Would the way to augment myexample.cf be to have a corresponding myexample.json next to it, and add it to the augments list in def.json? Are there some examples of this in the documentation I might have missed?

[eb4x]

Ha, ok so I think I'm getting the picture, atleast somewhat.

I added

"augments": [
  "$(sys.workdir)/atoms.json"
  "$(sys.inputdir)/services/myexample.json"
],

and

{
  "variables": {
    "myexample.mystring": {
      "value": "this is the augmented string"
    },
    "myexample.mylist": {
      "value": [ "this", "is", "the", "augmented", "list" ]
    }
  }
}

and these seem to act like what I'd expect defaults to do. It's not a great experience though, a separate file to read and figure out whether a default exists or just how error-prone it can be writing json and getting the "bundle.varname" syntax combo right.

[nickanderson]

Yeah your getting there. And yes, there are trade offs to separating the data out from the policy like that, sometimes things being far away semantically from the policy.

You might find this interesting: https://cfengine.com/blog/2018/hacking-custom-variables-for-additional-augments-in-cfengine/

[nickanderson]

I should also mention that Enterprise CMDB builds data files for each host based on the groups they are in and that's yet another way to do this.

https://cfengine.com/blog/2023/groups-app-sneak-peek/
https://cfengine.com/blog/2024/feature-friday-35-groups-in-mission-portal/

[basvandervlies]

Erik, Maybe this blog can explain the usage of augments files and cfengine * https://cfengine.com/blog/2018/missing_ok-and-multiple-augments-in-3-12-0/ What I am also using is `ifelse`: * https://docs.cfengine.com/docs/master/reference/functions/ifelse/ There is even whole framework for configuring services via mustache/json files. It can be installed via cfbs: * https://build.cfengine.com/modules/surf-cfengine-library/ * https://github.com/basvandervlies/cf_surfsara_lib Regards Bas

…

On 06/03/2026 15:54, Erik Berg wrote: Ha, ok so I think I'm getting the picture, atleast somewhat. I added "augments": [ "$(sys.workdir)/atoms.json" "$(sys.inputdir)/services/myexample.json" ], and { "variables": { "myexample.mystring": { "value":"this is the augmented string" }, "myexample.mylist": { "value": ["this","is","the","augmented","list" ] } } } and these seem to act like what I'd expect defaults to do. It's not a great experience though, a separate file to read and figure out whether a default exists or just how error-prone it can be writing json and getting the "bundle.varname" syntax combo right. — Reply to this email directly, view it on GitHub <https://github.com/ cfengine/core#6050#discussioncomment-16024282>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ AADJKB2S3NZM4G44NQOCT434PLRBBAVCNFSM6AAAAACWIF65D2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBSGQZDQMQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- -- Bas van der Vlies | High Performance Computing & Visualization | SURF| Science Park 140 | 1098 XG Amsterdam | T +31 (0) 20 800 1300 | ***@***.*** | www.surf.nl