Project

General

Profile

Actions
Copy link

Bug #4615

closed

If a deployment is really long, all reports are displayed as in "no answer"

Added by Nicolas CHARLES almost 11 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
François ARMAND
Category:
Web - Compliance & node report
Target version:
2.6.20
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

When deployment gets long, the rules compliances are all in no answer
The issue there is that the phases of deployment are:
  1. coputing everything
  2. updating rule serial
  3. updating node configuration
  4. writing promises
  5. saving expected reports

The rule compliance is based on the Rule id and rule serial, but if step 3 or 4 are quite long, then expected reports are not up to date with the serial for more than 5 minutes, hence the dreaded no answer

We could either delay the saving of rule serial in ldap, or change the way we gather the data for the reporting

Francois, what do you think of it ?

Actions
Copy link
 #1

Updated by François ARMAND almost 11 years ago

I thing that #4242 will help, bringing back the LDAP writing time to seconds.

But of course, it's just a false correction. We have the same pb is writing promises takes more than several minutes, of if checking them with cfe takes several minutes...
We should take the time to see how to correct that so that it can't happen anymore (i.e: either all linked information updated in a transaction, or an algo not sensitive to that).

Of course, either solution is not a bug correction but a major evolution on Rudder... So I don't thing we will be able to correct that in 2.6. Do you thing it is of any use to try to mitigate that, with all the risk it takes, compared to say use 2.10 and up to correct that ?

Actions
Copy link
 #2

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions
Copy link
 #3

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions
Copy link
 #4

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions
Copy link
 #5

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions
Copy link
 #6

Updated by Nicolas PERRON over 10 years ago

  • Target version changed from 2.6.17 to 2.6.18
Actions
Copy link
 #7

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 2.6.18 to 2.6.19
Actions
Copy link
 #8

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.19 to 2.6.20
Actions
Copy link
 #9

Updated by François ARMAND almost 10 years ago

  • Status changed from Discussion to Rejected

There is no good solution to that one until 3.0 safe the multiple performance improvment we added that will help reduce the windows for the inconsistency.

In 3.0, the story is complettly different, and we should handle that case in a robust way.
The only case where the reporting is still a little strange is when we just added a node, before the end of the promise generation, we are in an "unknow" state for that node. (it can also happen if data are deleted). The case is handle with a "no know expected reports - please trigger a generation" status.

So closing that one (can't do anything for 2.10/2.11, solved in 3.0), and really happy to do so - it was clearly an architecture fault :)

Actions
Copy link

Also available in: Atom PDF