Bug #4615
closed
If a deployment is really long, all reports are displayed as in "no answer"
Added by Nicolas CHARLES about 10 years ago.
Updated about 9 years ago.
Category:
Web - Compliance & node report
Description
When deployment gets long, the rules compliances are all in no answer
The issue there is that the phases of deployment are:
- coputing everything
- updating rule serial
- updating node configuration
- writing promises
- 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 ?
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 ?
- Target version changed from 2.6.12 to 2.6.13
- Target version changed from 2.6.13 to 2.6.14
- Target version changed from 2.6.14 to 2.6.16
- Target version changed from 2.6.16 to 2.6.17
- Target version changed from 2.6.17 to 2.6.18
- Target version changed from 2.6.18 to 2.6.19
- Target version changed from 2.6.19 to 2.6.20
- 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 :)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Nicolas PERRON 
Updated by Matthieu CERDA