FOG 1.2.0 - issue with deployment information screen
-
Hi All,
I don’t know if this is a bug or normal activity - doesn’t seem “normal”.
Today I deployed a room of 24 PC’s and PXE booted all of them. FOG started deploying the first ten on its list. The remaining fourteen displayed a message like “Waiting for a slot: there are 0 to 13 PC’s in front of me” depending on where it was in the queue.
After these fourteen had been in the queue for about nine minutes, the position in the queue for all the remaining PC’s slowly changed so that by ten minutes in the queue they all reported “0 PC’s in front of me”.
I know you guys are extremely busy fixing more important issues than this. As it doesn’t stop FOG working, maybe it is a fix to be put on the wish list for the next version?
TIA
-
Did the 13 in queue start imaging on there own or did they just keep reporting 0 pcs in front of me?
-
Hi Tom,
No they just continued to wait and deploy as normal. Originally I thought someone may have forced the deployment of the remaining hosts on the task list, but no.
Strange…
-
“Wait and deploy as normal?”
So as the 0 marker, the one in front completed, this one would start and the “rest” in the queue would go up one?
-
Sorry Tom,
no, the information (counter) remained at zero after the initial 10 minutes of queuing. As the deploying ones finished and cleared from the task list the next one in line started deployment until all 24 were deployed.
It’s almost as if the deployment engine either at the host or server end lost communication after 10 minutes then without any fresh information to go on, used zero as a “best guess”.
I know that’s not very technical, but from an end-users perspective, that what seemed to happen…
-
[QUOTE]Today I deployed a room of 24 PC’s and PXE booted all of them. FOG started deploying the first ten on its list. The remaining fourteen displayed a message like “Waiting for a slot: there are 0 to 13 PC’s in front of me” depending on where it was in the queue.
After these fourteen had been in the queue for about nine minutes, the position in the queue for all the remaining PC’s slowly changed so that by ten minutes in the queue they all reported “0 PC’s in front of me”.[/QUOTE]
[QUOTE]As the deploying ones finished and cleared from the task list the next one in line started deployment until all 24 were deployed. It’s almost as if the deployment engine either at the host or server end lost communication after 10 minutes then without any fresh information to go on, used zero as a “best guess”.[/QUOTE]
This has been happening on our system as well exactly as fre2709 has described.
FOG 1.1.0
Ubuntu 12.4 -
Hi Tom,
Just in case I was going mad, I watched the deployment of another room to see if had been a one-off. But no, exactly as I described in my previous post.
After all queued hosts reached the 9 minute marker the last one, which said “13 PCs in front of me” started counting down. As soon as I noticed this I checked all the others and they were doing the same until all hosts said “0 PCs in front of me”. The time in queue continued to count up by the minute.
When the first batch of 10 hosts started to finish, the next in line started to deploy until I was left with three still queued. They all still said “0 PCs in front of me” and the time in queue continued to count up. I took pictures of the three host screens but couldn’t attach them to the post - kept getting errors even as a ZIP.
Are there any logs or other files you need to see from my FOG server to diagnose the problem? However, as Michael Shocklee is getting the same it must be a coding error in version 1.1.0 to 1.2.0…
-
It’s an aesthetic bug then. I’ll see what I can figure out. So, just to clarify, the queueing itself is working properly, just the display of the “in front of me” is not?
-
In my experience, that is correct.
-
I can confirm that everything appears normal apart from the “in front of me” count, as per Michael Shocklee’s post…
-
So i’m seeing what and why and where the issue is.
It’s not really an issue, but rather a designed feature.
There is a timeout as you guys suspected and that is set in:
FOG Configuration->FOG Settings->General Settings FOG_CHECKIN_TIMEOUTIt is defaulted to 600 (10 minutes) and perhaps needs to be set longer in some environments?
That said, I think this is why you’re seeing the issue in that the “checkin time” vs the time they’ve been waiting has been surpassed, so it thinks it’s the next in line. The actual ordering is lost. You could try 15 or 20 minute timeout and see if it gives better results.
I think the idea of the timeout is to allow systems that have been waiting without other taskings happening, a chance to run in. For example, in the case somebody started a job on a system, but then decided to power it down. The now checked in, but powered down system would hold up all the rest of the systems queued behind it for ever if this didn’t change.