Deploy (Unicast): Wrong number of client per node.

[Tom Elliott]

DOes it actually image 4 clients on the system or is one of the clients waiting for a slot to free up?

[mp12]

@Tom-Elliott it actually image 4 clients.

[mp12]

@Wayne-Workman I tried some scenarios (lots). With different number of max clients and different number of clients which get a deploy. See spreadsheet for details.

0_1455537297048_fog_testing.xlsx

[Tom Elliott]

@mp12 Is this still a problem?

I updated the code base for the getUsed/getQueued hosts. I’m not sure it will do anything, but status update would still be nice if at all possible.

[mp12]

@Tom-Elliott upgraded to r6285.

No effect here. Started task with four clients.
Max client on both nodes is set to two.

Only node1 processes the four image tasks.

[Tom Elliott]

@mp12 This seems, to me, to be a timing issue. What happens if you slowly let the clients check in rather than all try to beat the clock?

[mp12]

@Tom-Elliott thanks for the tip.

Same setup as before.

node1 max client 2
node2 max client 2
number of deployed clients 4

Started the deploys with a delay of 10 sec. between each client.
I tested it via basic tasks/deploy and with the clients boot menu/quick image.

The clients got split correctly. This seems to fix the problem?!

Tested a delay of 7 sec. and the split got messed up.

[Tom Elliott]

@mp12 this gives me a starting point on what I can do to try to fix the problem you’re seeing. I don’t know why time matters but apparently it does.

I’ll see if I can make things work properly but trying to race between quite literally seconds is not a simple feat.

[Wayne Workman]

@Tom-Elliott Don’t let the clients start themselves - have the server do it.

[Tom Elliott]

@Wayne-Workman What?

[mp12]

@Tom-Elliott maybe a delay between the WOL should be enough? I think 10 sec. should be enough and it also protects the electrical fuse against defective.

[Wayne Workman]

@Tom-Elliott The only way that a queue would accidentally overfill is if the clients were checking for themselves and then seeing that a slot is open (when two check at once) and going ahead and starting themselves - instead of the server evaluating each request and saying yes or no to it.

Sounds like it takes roughly 7 seconds from a client thinking it’s good to go - to the queue count being updated.

[Tom Elliott]

I believe this is now fixed, but confirmation would be good. I’m solving, but it can be unsolved again if this is not working still/again.

[mp12]

@Tom-Elliott

FOG r6439

Still having problems.

node1 max client: 3
node2 max client: 3
number of clients in the deployed group: 6

–> node1 deploys five clients.
–> node2 deploys zero clients.
–> one client is queued.

[Tom Elliott]

@mp12 What kind of tasks are you running? Are the ALL deploy’s?

[mp12]

@Tom-Elliott

I am running a instant group deploy (basic tasks). The group has six clients.

[Tom Elliott]

@mp12 THey are not multicast?

[mp12]

@Tom-Elliott

No multicast!
Just a normal deploy “type=1”

[Tom Elliott]

@mp12 And you’re 100% sure you’re running 6439? I ask because I tested this same type of thing quite a lot yesterday.

Granted with only two hosts, but I started both systems at the same time. One won in the battle and the other was pushed to the back.

[mp12]

@Tom-Elliott

Yes 100% sure. Just did an upgrade when I read your post from yesterday.
I will test with two and four clients tomorrow.