Project

General

Profile

Actions

Bug #2860

closed

priority does not appear to have an effect for directives derived from multi-instance techniques

Added by Michael Gliwinski over 11 years ago. Updated over 11 years ago.

Status:
Released
Priority:
2
Category:
Web - Config management
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

This is on Rudder 2.4 beta3

According to the tooltip of Priority field in directive settings, for multi-instance techniques, a higher priority (lower number) means a directive will be applied first. This does not appear to work.

I've configured a couple of directives based on 'Enforce a file content', most of them are set to default priority 5, but one of them is set to priority 2, and another to priority 8. However in /var/rudder/share/{NODE_UUID}/rules/cfengine-community/checkGenericFileContent/3.0/checkGenericFileContent.cf file generated for the node, I can see that a directive with priority 5 is first (i.e. index=1), the directive with priority 8 is second, then there are a couple of directives with priority 5 and finally the one with priority 2 is last.

I've also tried deleting and re-creating the directive with priority 8, but it still ended up second in the generated file.

Let me know if I'm doing something wrong, and what I can do to help debug this.

Actions #1

Updated by Nicolas CHARLES over 11 years ago

  • Status changed from New to 2
  • Assignee set to Nicolas CHARLES
  • Priority changed from N/A to 2
  • Target version set to 2.4.0~rc1
Actions #2

Updated by Nicolas CHARLES over 11 years ago

Indeed, the order doesn't seem to be respected. I'm checking what could go wrong
Thank you Michael

Actions #3

Updated by Nicolas CHARLES over 11 years ago

Ha, this is an interesting bug. We make sure several time that the order is correct, but several time we pipe the data through Map, which breaks the order :(

Actions #4

Updated by Nicolas CHARLES over 11 years ago

  • Status changed from 2 to Pending technical review
  • % Done changed from 0 to 100

Applied in changeset commit:f2570bba8bc6e4f8415ceed0758d2be8ab8eabc2.

Actions #5

Updated by Nicolas CHARLES over 11 years ago

Michael, I've just pushed a patch that should correct your problem. If everything goes right, you should have nightly built version of Rudder available tomorrow morning to test it.
Thank you !

Actions #6

Updated by Michael Gliwinski over 11 years ago

Nicolas CHARLES wrote:

Michael, I've just pushed a patch that should correct your problem. If everything goes right, you should have nightly built version of Rudder available tomorrow morning to test it.

That's brilliant, I'll switch to nightlies and test it as soon as I can. Thanks!

Actions #7

Updated by Michael Gliwinski over 11 years ago

Nicolas CHARLES wrote:

Michael, I've just pushed a patch that should correct your problem. If everything goes right, you should have nightly built version of Rudder available tomorrow morning to test it.

OK, I checked this in the nightly build, and priority now does have an effect, but I also see CFEngine applying the promises in a different order.

Some more details:

I have two checkGenericFileContent directives applying changes to the same file (basically what I'm trying to do is have a generic directive that sets up global configuration and then other rules which apply to different servers add some application-specific lines). If I set directive1 (global) to priority 2 and directive2 (app-specific) to priority 8, in the checkGenericFileContent.cf file generated for a node I can see that directive1 is given index 1 in generic_file_content_payload (and associated) array, while directive 2 is given index 2.

However on the node I ran cf-agent -v in the output I can see that it applies directive 2 first and directive 1 second.

Maybe I'm misunderstanding something, but does that look right? I started looking into it and I can't find in CFE docs e.g. what's the order of indexes returned by getindices, or what's the order in which lists are iterated, so I'm no longer sure if what I'm expecting is right.

I also tried swapping the priorities, which did change the order in which entries were generated in arrays in the .cf file, but it didn't seem to affect the order in which promises were applied on the node.

Do you know if this is right? I.e. am I misusing it trying to rely on order?

Actions #8

Updated by Nicolas CHARLES over 11 years ago

Michael Gliwinski wrote:

Nicolas CHARLES wrote:

Michael, I've just pushed a patch that should correct your problem. If everything goes right, you should have nightly built version of Rudder available tomorrow morning to test it.

OK, I checked this in the nightly build, and priority now does have an effect, but I also see CFEngine applying the promises in a different order.

Some more details:

I have two checkGenericFileContent directives applying changes to the same file (basically what I'm trying to do is have a generic directive that sets up global configuration and then other rules which apply to different servers add some application-specific lines). If I set directive1 (global) to priority 2 and directive2 (app-specific) to priority 8, in the checkGenericFileContent.cf file generated for a node I can see that directive1 is given index 1 in generic_file_content_payload (and associated) array, while directive 2 is given index 2.

So far, the priority will :
- apply only the directive of highest priority, is the directive is Unique
- order multi-instance directives, based on their priority, only within a rule. If the directives are in seperate rules, then the order cannot be (as of the 2.4) enforced

However on the node I ran cf-agent -v in the output I can see that it applies directive 2 first and directive 1 second.

Maybe I'm misunderstanding something, but does that look right? I started looking into it and I can't find in CFE docs e.g. what's the order of indexes returned by getindices, or what's the order in which lists are iterated, so I'm no longer sure if what I'm expecting is right.

I also tried swapping the priorities, which did change the order in which entries were generated in arrays in the .cf file, but it didn't seem to affect the order in which promises were applied on the node.

Do you know if this is right? I.e. am I misusing it trying to rely on order?

So far, we don't have order than span across differents rules, unfortunately. That would need a far too big change of logic for the upcoming 2.4
Sorry about that

Actions #9

Updated by Michael Gliwinski over 11 years ago

Nicolas CHARLES wrote:

So far, we don't have order than span across differents rules, unfortunately. That would need a far too big change of logic for the upcoming 2.4
Sorry about that

OK, that works, i.e. if I move the directive into the same rule, they are applied in correct order. However, I don't actually know why that works, i.e. the only difference between the generated checkGenericFileContent.cf file is the UUIDs in generic_file_content_uuid array. That couldn't be affecting the order in which promises are applied, no?

No worries, I can work with that, just wanted to understand what is affecting the order "under the hood".

Actions #10

Updated by Nicolas CHARLES over 11 years ago

Michael Gliwinski wrote:

Nicolas CHARLES wrote:

So far, we don't have order than span across differents rules, unfortunately. That would need a far too big change of logic for the upcoming 2.4
Sorry about that

OK, that works, i.e. if I move the directive into the same rule, they are applied in correct order. However, I don't actually know why that works, i.e. the only difference between the generated checkGenericFileContent.cf file is the UUIDs in generic_file_content_uuid array. That couldn't be affecting the order in which promises are applied, no?

It's related to the "under the hood" way of how rules are applied to node : they are applied rule by rule. That's why we can't reorder easily between rules on the upcoming 2.4

No worries, I can work with that, just wanted to understand what is affecting the order "under the hood".

Sorry about this limitation. We'll try to improve

Actions #11

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.4.0~rc1 to 2.4.0~beta5
Actions #12

Updated by François ARMAND over 11 years ago

  • Status changed from Pending technical review to Released

I love to do technical review on bug's correction like that:

- it was cross-tested by our lovely community
- the correction is one line and a no brainer.

Thanks !

Actions

Also available in: Atom PDF