Project

General

Profile

Actions

Bug #5806

closed

Splaytime duration must be STRICTLY inferior to the agent period to avoid random run frequency

Added by Nicolas CHARLES over 7 years ago. Updated over 7 years ago.

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

Description

If splay is equal to the run period, then the agent (randomly) doesn't run.

For example, on an user infrastructure, on 11 nodes out of 139, using a splaytime that has the same value as run period lead to some runs skipped, and I end up having a run every 10 minute, except sometimes 5 minutes.

It does have a very radom characteristic (and on less than 10% of machines), but we should prevent having same splaytime as frequency

Actions #1

Updated by François ARMAND over 7 years ago

  • Subject changed from Configuring splaytime with the same frequency as the agent may cause agent to "skip" runs to Configuring splaytime with the same duration as the agent period may cause agent to "skip" runs

I'm not sur I understand the intents here. To me, the bug seems to be that runs are skipped, not that the splaytime can be equals to the run period.

If the bug is really the splay time duration, could you explain a little more what do we want to forbid ?

For example, is there a problem of having a 5 minute period for the agent run and a splaytime of 10 minutes ?

Thanks,

Actions #2

Updated by François ARMAND over 7 years ago

  • Status changed from New to Discussion
  • Assignee changed from François ARMAND to Nicolas CHARLES
Actions #3

Updated by Nicolas CHARLES over 7 years ago

  • Assignee changed from Nicolas CHARLES to François ARMAND

I don't understand this question. You cannot configure in the wev interface a splay higher than the frequency. So there may (and probably is) an issue with defining 10 minutes splay and 5 minutes run interval, but it is already forbiden

Actions #4

Updated by François ARMAND over 7 years ago

Well, the question was: is there a problem on an the agent side ? Is it a technical/hardcore limitation to have a splaytime strictly inferior to the period ?

If so, is there a minimum delta between splay duration and agent period ? For example, is it ok to have a 4'59'' splay duration with a 5' period ?

Actions #5

Updated by François ARMAND over 7 years ago

  • Assignee changed from François ARMAND to Nicolas CHARLES
Actions #6

Updated by Nicolas CHARLES over 7 years ago

  • Assignee changed from Nicolas CHARLES to François ARMAND

It is an hardcoded limitation in the agent

If splay is equal to the frequency, then it (randomly) don't run. The problem is only on the agent side, and not on all agent (based on the random nature of the splay computation)
I guess that 4m59 would be ok, if the language permitted it, but we can only have splay in a number of minutes.

Either way, it makes no sense to allow an invalid parameter in the webapp

Actions #7

Updated by François ARMAND over 7 years ago

  • Subject changed from Configuring splaytime with the same duration as the agent period may cause agent to "skip" runs to playtime with the same duration as the agent period may cause agent to "skip" runs
Actions #8

Updated by François ARMAND over 7 years ago

  • Subject changed from playtime with the same duration as the agent period may cause agent to "skip" runs to Splaytime duration must be STRICTLY inferior to the agent period to avoid random run frequency
  • Description updated (diff)
  • Status changed from Discussion to 8
  • Priority changed from N/A to 2
Actions #9

Updated by Vincent MEMBRÉ over 7 years ago

  • Description updated (diff)
  • Status changed from 8 to Pending technical review
  • Pull Request set to https://github.com/Normation/rudder/pull/676
Actions #10

Updated by Vincent MEMBRÉ over 7 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions #12

Updated by Vincent MEMBRÉ over 7 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.10.8 and 2.11.5, which were released today (16/12/14)

Actions #13

Updated by Benoît PECCATTE over 7 years ago

  • Category changed from 14 to Web - Config management
Actions

Also available in: Atom PDF