action #71224
closed
- Status changed from New to Rejected
- Assignee set to okurz
Checked in journal of osd but have found nothing unusual. In this rare case I would actually not do anything and also not change the alert.
I remember that a correct time is mainly required for API keys to work. Can we actually somehow calculate/look up the exact value when API keys will start to break?
Based on the observation that communication between workers and webui did not break I assume that either the limit is higher or workers were shifted in time just as well as webui :) Nevertheless we want the alert to trigger before communication breaks down, right? Also we should have a proper time for logs, etc. And 30s is a lot
- Status changed from Rejected to In Progress
- Assignee changed from okurz to nicksinger
Just yesterday we saw the same alert again which also again recovered after 2.5h. I saw that we only have suse internal hosts configured as ntp upstream servers so adding yet another one but from the ntp pool might ease the issue? It could also rule out that we have some different issue on our host.
Besides that I also saw that we still use ntpd on OSD. Chronie is installed but not used and might be yet another measure we could try out.
I am glad you found this older ticket :) And good idea about consolidating the ntp/chrony thing. I think it's not the first time you confuse "chrony" and "cronie" ;)
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
perfect. MR merged. I checked that it was applied correctly and checked logs on osd. ntpd started up fine again and is using the SUSE internal NTP server by default. It would probably take some months for any next incident to see if the fallback to external NTP servers works so this should be good enough for now.
Also available in: Atom
PDF