Bug #2398
closed
Reporting is broken when in the same PI => Install only + update only the same package
Description
My Configuration Rules stay at 0% compliance, the rule use only one Policy Instance based on "Package management for Debian / Ubuntu / APT systems". The report indicate severity "Unknown" for this configuration rules.
The Policy Instance was created in two times :
- 1) creation with 2 sections in parameters "Debian/Ubuntu packages #1"
---1) package name : postfix
----) Install only (don't update)
---2) package name : postfix
----) Install only (don't update)
=> Configuration Rules : 100% Compliance
- 2) update PI to add a new section in parameters "Debian/Ubuntu packages #1"
---1) package name : postfix
----) Update only (don't install)
=> Configuration Rules : 0% Compliance
Updated by Francois BAYART over 12 years ago
- Assignee deleted (
François ARMAND)
I forgot to put the question ... so the question is : is it normal ?
Updated by Nicolas CHARLES over 12 years ago
- Description updated (diff)
- Category changed from Web - Config management to Web - Compliance & node report
- Assignee changed from François ARMAND to Nicolas CHARLES
- Priority changed from N/A to 1 (highest)
- Target version set to 2.3.7
This is a really interesting bug. I'm currently evaluating the impact.
Updated by Nicolas CHARLES over 12 years ago
This is the collision of two "problems".
Since we have twice the same component in this directive, with the same goal (install), cfengine execute only once the promises for postfix. Hence we have only one Success reports, and it is a success du to the way the reports are counted
A Directive is in success if it has only one success per component (and not per distinct component). In the case 1), we have 2 components identical, but only one success, so it is "ok", in the case 2), we have have 3 components identical, but two success, so it is not ok
The success count should definitively be improved, but it won't solve the erasure by cfengine of the identical promises... a unique identifier (or detecting identical choices?) should be used.
Updated by Nicolas CHARLES over 12 years ago
- Estimated time changed from 0.00 h to 8.00 h
Simply to change the way the reports are count is going to be a big task, and it will probably cause some compatibility issues with the techniques, as it might put in light some unfound bugs....
Updated by Nicolas CHARLES over 12 years ago
- Tracker changed from Question to Bug
Updated by Jonathan CLARKE over 12 years ago
- Subject changed from same PI => Install only + update only the same package to Reporting is broken when in the same PI => Install only + update only the same package
I see two quick fixes to do here:
1) Fix the reporting "counting" (second part of Nicolas' comment #4) so that we check that we have exactly the right number of reports for each component/key in a given PI. This should have been the case already, and was spotted thanks to this bug. This part will be handled in this ticket, and we should have a fix ready and tested by Thursday morning.
As a side effect, this will cause the case 1) reported by François (2 "postfix install" sections in the same PI) to produce 0% compliance, in the same way that the case 2) does. This is because all configuration for these two packages is identical ("postfix" and "install only"), so CFEngine detects this and only send one report, where we are expecting two.
2) To avoid this, I think that adding a mecanism to avoid duplicated identical sections would make sense. Two approaches are detailed in #2424 :
2.1) Silently drop any duplicated sections. This could be confusing for the user, but will avoid breaking reporting, and is in effect not deleting any data since we delete only an exact copy of existing data. This is a "quick win"...
2.2) Warn the user he's input a duplicate section and ask him what to do. This takes a bit longer, which is why we're considering 2.1 first.
Updated by Nicolas CHARLES over 12 years ago
- Status changed from New to Pending technical review
- % Done changed from 0 to 100
Applied in changeset 678f614c3d11cc06cf7d8d64bb42b998940ed806.
Updated by Nicolas CHARLES over 12 years ago
The reports are now correctly counted ! Thank you Francois for this bug report
Updated by François ARMAND over 12 years ago
The correction from Nicolas seems OK for me, but I proposed a little code refactoring to make the code more DRY and the difference for each case more apparent.
Nicolas, I let you review that proposal.
Updated by Nicolas CHARLES over 12 years ago
- Status changed from Pending technical review to Released
The proposal looks ok, thank you Francois !