Rudder

Assiging to Jon to get some feedback from him.

Duplicated by #5329

Sorry, bad bug closed! We keep that one, as the example is pretty good and clearly depicted the importance of the correction.

Work in Progress: https://github.com/Normation/rudder/pull/645

Nico, I set you for that one because it's likelly I won't be able to finish it.

For now, the logic to propagate what directive is overiden on which node to the update of expected reports is here. So it remains to do either 1/ or 3/ (2 is silly, has we have the information in base, it is not more difficult to write the CF3DraftId than a boolean).

So, if 1/ is chosen, the "update expected reports" logic must be updated to filter out directive for rule/node that are overriden.
If 3/ is chosen, in place of filtering out like in 1/ we need to add the relevant information in database ( expectedReportsNodes table is already updated with a "overriden" field - perhaps overriden_by would be better), and then use it when merging expected and received reports, at least managing case where we get a reports that should have been overriden (=> unexpected) and when we actually don't get a report (==> not applicable, or - not sure if necessary - a new Status, "overriden". But I don't see the point, it is really not applicable, and we can forge a message "that component is overiden by an other directive blablable).

For now, the first solution is implemented (filtered out overriden report without specific reporting on them).

Applied in changeset 02a1532f8d7a85d48f7129e2a6e61b33ba64ce57.

This bug has been fixed in Rudder 3.0.0~beta1 which was release on 01/12/2014.

• Announcement
• Changelog
• Download information: https://www.rudder-project.org/site/get-rudder/downloads/