Package promise had no package_method attribute

[Beto]

Since upgrading from cfengine-community 3.18 to CFEngine Enterprise 3.21.5 I'm seeing this on every host every time the agent runs:

info: Package promise had no package_method attribute so it's being assigned a value of 'generic' as default.

.

This is repeated from 6 to ~150 times during each execution probably depending on classes.

This seems like a misclassed message that should only be written in verbose or debug mode.

Any ideas?

Here's a sample bundle to show the issue:

body common control
{
        bundlesequence => {
                "main",
        };
}

body file control
{
  inputs => { "/var/cfengine/inputs/lib/packages.cf" };
}

bundle agent main
{
        methods:

                "any" usebundle => packages;
}

bundle agent packages {
  vars:
    redhat_7::
      "redhat_7_baseline_packages"
        comment => "install rhel7 baseline packages",
        slist   => {
          "at",
          "audispd-plugins",
          };

      "redhat_7_baseline_packages"
        comment => "install rhel7 baseline packages",
        if      => "g_ovpa",
        slist   => {
          @(redhat_7_baseline_packages),
          "xinetd"
          };

      "redhat_7_real_packages"
        comment => "install rhel7 real machine packages",
        slist   => {
          "device-mapper-multipath",
          "device-mapper-multipath-libs",
          "sg3_utils"
          };

      "redhat_7_developer_packages"
        comment => "install rhel7 developer packages",
        slist   => {
          "gcc"
          };

      "redhat_7_delete_packages"
        comment => "rhel7 wireless packages",
        slist   => {
          "iwl6050-firmware",
          };

      "redhat_7_delete_packages"
        comment => "rhel7 firmware packages",
        slist   => {
          @(redhat_7_delete_packages),
          "ivtv-firmware" };

      "redhat_7_delete_packages"
        comment => "rhel7 miscelleneous packages",
        slist   => {
          @(redhat_7_delete_packages),
          "NetworkManager-tui",
          "NetworkManager-team",
          "NetworkManager-config-server",
          };

      "redhat_7_delete_packages"
        comment => "rhel7 ovpa packages",
        slist   => {
          @(redhat_7_delete_packages),
          "xinetd"
          };

  packages:
    redhat_7::
      "$(redhat_7_baseline_packages)"
        comment         => "Install rhel7 baseline packages",
        policy          => "present",
        version         => "latest",
        package_module  => yum;

      "$(redhat_7_real_packages)"
        comment         => "Install rhel7 real machine packages",
        policy          => "present",
        version         => "latest",
        package_module  => yum;

      "$(redhat_7_developer_packages)"
        comment         => "Install rhel7 developer packages",
        policy          => "present",
        version         => "latest",
        package_module  => yum;

      "$(redhat_7_delete_packages)"
        comment         => "Delete rhel7 packages",
        policy          => "absent",
        package_module  => yum;

}

[Beto]

I tried 

        "control_executor_mailfilter_exclude": {
          "value": [ ".*no package_method attribute.*" ]

but it's not working for some reason. :(

[Markus Rexhepi-Lindberg]

I noticed this while upgrading from 3.21.4 to 3.21.5 as well.

--
Markus

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/87e1a57d-4e2c-4b27-a160-ca1815a3a739n%40googlegroups.com.

[Bas van der Vlies]

This is a bug. The message should be “DEBUG” but is “INFO”. They have fixed it but not yet released a new cfengine 3.21 version, see:
* https://northerntech.atlassian.net/browse/CFE-4398

[Bas van der Vlies]

Looks strange bu I suppress it by:
```
packages:


!version_specified::


"$(package)"


policy => "$(action)",


package_method => generic,


options => { "$(options)" };
```

I only use version 2 and do not version 1 package management any more. I
will remove it when a new version has been released.

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

[Beto]

Thanks, Bas and Markus!

[craig.c...@northern.tech]

Strangely I sent a reply yesterday that apparently didn't make it to the list.

---

Yes, sorry about the noise. The logging around package promises and why the system would choose v1 (methods) or v2 (modules) was rather lacking so we made some improvements but sadly set the log level a bit wrong.

All of these issues should be fixed in master and 3.21.x for next releases 3.24.0 (New LTS coming soon!) and 3.21.6 (coming later).

And yes, adding package_method => "generic" should fix v1(method) promises.

Where are you seeing the info messages? 

- In emails? That is the ONLY case where the control_executor_mailfilter_exclude would work and even then controls/cf_execd.cf would have to have the cf-agent commands modified to include --info log level for you to get that noisy package info level message.

- In /var/cfengine/outputs? Did you change controls/cf_execd.cf and add --info to the cf-agent commands that are run?

- Are you running cf-agent some other way besides cf-execd?

Because we examine many attributes in packages promises to determine which version to use you can include the package_method attribute along with package_module and policy which will cause v2 package modules to be used.

Like this:

packages:
  "mutt"
    policy => "present",
    package_method => generic,
    package_module => apt_get;

Looking at debug output of an agent run with that policy I see that v2 package modules are used as desired:

verbose: Using v2 package promises (package_module)

debug: New package promise handler

verbose: P: .........................................................

verbose: P: BEGIN promise 'promise_main_cf_12' of type "packages" (pass 1)

verbose: P:    Promiser/affected object: 'mutt'

verbose: P:    Part of bundle: mpf_main

verbose: P:    Base context class: any

verbose: P:    Stack path: /default/mpf_main/packages/'mutt'[1]

debug: Getting supported API version.

debug: Opened fds 4 and 7 for command '/var/cfengine/bin/cfengine-selected-python /var/cfengine/modules/packages/apt_get supports-api-version'.

[Craig Comstock]

To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/a40e51d2-6edb-4a23-b43e-011864c83a8a%40surf.nl.

--

Craig Comstock (he/him)
CFEngineer/Digger | CFEngine
Kansas, USA
Northern.tech | Securing the world's connected devices

[Beto]

Hey Craig,

We see these messages in email and /var/cfengine/outputs.

We have inform => "true" in controls/cf_agent.cf

We haven't added anything to cf-agent execution in controls/cf_execd.cf

We only use cf-execd to run cf-agent.

[Nick Anderson]

Hey Beto,

You mentioned trying this …

"control_executor_mailfilter_exclude": {
      "value": [ ".*no package_method attribute.*" ]

That looks like Augments format to me. Specifically, it looks like the newer format of the variables key. Is this in def.json or is it in host_specific.json ? (ref https://docs.cfengine.com/docs/3.21/reference-language-concepts-augments.html#augments-files)

If it's in host_specific.json then I think you will need to adjust it to specify the default namespace and the def bundle scope like this:

"default:def.control_executor_mailfilter_exclude": {
      "value": [ ".*no package_method attribute.*" ]

Another thing to be sure of is that cf-execd has been re-started since you changed that setting.

We see these messages in email and /var/cfengine/outputs.

If the mailfitler exclude is properly picked up you should not see them in email, just in /var/cfengine/outputs.

We have inform => "true" in controls/cf_agent.cf

Generally I discourage that for unattended periodic executions, especially combined with email it can create a lot of noise that mail admins might not love (but depends very much on your scale, and how many changes CFEngine is generally making).

[Beto]

This is in def.json vars section:

        "control_executor_mailfilter_exclude": {
          "value": [ ".*no package_method attribute.*", ".*regline.*" ]
        }

Yeah, you're right about inform.  Before the upgrade I had mail filters in cf_execd.cf that suppressed all but error messages.

I've always used inform => true in cf_agent.cf.  This made it easy to deflect queries from coworkers when they break something, and the inevitable question arises: "did cfengine change...?".  I tell them to grep /var/cfengine/outputs lol.

[Beto]

Evidently the control_executor_mailfilter_exclude wasn't working because I used this example from the reference:

{
  "variables": {
    "default:def.control_executor_mailfilter_exclude": {
      "value": [ ".*ps output line.*", ".*regline.*" ]
    }
  }
}

I think this should be:

{
  "variables": {
    "def.control_executor_mailfilter_exclude": 
     [ ".*ps output line.*", ".*regline.*" ]
    }
  }
}

This is what I have now and it's working fine:

        "control_executor_mailfilter_exclude": [ ],
        "control_executor_mailfilter_include": [
          "\\s*(Unable to establish|R:).*",
          "\\s*error:\\s+.*installing.*",
          "\\s*error:\\s+.*readyaml.*",
          "\\s*info: Purging.*"
        ],

[Nick Anderson]

Ah great, you want to open a pull request?

https://github.com/cfengine/masterfiles/blob/master/MPF.md#configure-lines-that-should-be-excluded-from-emails-sent-by-cf-execd

--

You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/0a369387-a155-4440-983f-a242e8f1566cn%40googlegroups.com.

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

Argh!  It's just started hitting us also.

As part of our move towards 3.21 and 3.24, we are trying to pull up to the latest 3.18 to give ourselves a stable jumping-off point.  (Yes, I know 3.18 is now EOL, but we've still got a 3.12 lurking locally, and I even saw a 3.10.  So I'm working hard to try to do the right thing.)

This new reporting glitch is a new bug WITHIN the 3.18 series.  Things were good all the way up to and including 3.18.7.  But this suddenly appeared at 3.18.8, and is causing us some annoyance.

Why introduce such a visible change just before EOL-ing a release-series?

I know 3.18 is now EOL.  But given that this NEW BUG was introduced at the last minute, please could the fix (presumably CFE-4398) be applied (cherry-picked) to the 3.18 series?  Please?

CFE-4398 makes the inaccurate claim "fixed".  "Inaccurate"?  Yes, because it was not fixed in all the places it had been introduced.

I would re-open CFE-4398 and add a comment there but I don't have that access.

Thanks.

And happy Christmas!

-- David Lee

[Nick Anderson]

Hi David,

Why introduce such a visible change just before EOL-ing a release-series?

As with most bugs, we didn't expect the change to introduce a problem.

I know 3.18 is now EOL. But given that this NEW BUG was introduced at the last minute, please could the fix (presumably CFE-4398) be applied (cherry-picked) to the 3.18 series? Please?

I can't see that we would pick up maintenance for the EOL branch do builds and cut a new release. It doesn't make sense for us to pick changes back to 3.18.x that we have no intention of releasing but you could certainly pick the changes back to 3.18 and build yourself.

These sort of things are something we generally would consider doing for enterprise customers as one-off builds. Beyond that it might be possible to do as paid development / professional services / extended support.

Happy Feature Friday #41, and Happy Holidays!

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

Nick,

Many thanks for your reply.

I think we can live with it for now.  As part of my "running hard to seem to stay still" I hope to start us on the pilgrimage towards 3.21 (MPF, then binaries) over the next few months, so that will probably be our best way out of this minor annoyance.  (Of course the 3.18->3.21 journey will involve navigating "rxdirs" and the change from "main" to "mpf_main"... both in our noticeably mixed-version environment.)

We've already come a long way since being locked on 3.10 and non-MPF a few years ago; just before Christmas I had introduced our first ever use of "trigger_upgrade" to pull some recalcitrant straggling machines up to 3.18.   Indeed, it was my jumping to 3.18.8 for this exercise on them (and a couple of others) that introduced this fresh problem there.

Thanks again.

All the best.

-- David Lee

[Aleksey Tsalolikhin]

On Thu, Jan 23, 2025 at 11:03 AM t.d...@servicemusic.org.uk <t.d...@servicemusic.org.uk> wrote:

We've already come a long way since being locked on 3.10 and non-MPF a few years ago; just before Christmas I had introduced our first ever use of "trigger_upgrade" to pull some recalcitrant straggling machines up to 3.18.   Indeed, it was my jumping to 3.18.8 for this exercise on them (and a couple of others) that introduced this fresh problem there.  

You've come a long way, David!  =) Well done, sir, and keep it going!

Aleksey