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

[mp12]

Doesn’t FOG split the clients correctly to fulfill the max client option?

A deploy with 6 clients is split into:

• First node serves 4 clients.
• Secound node serves 2 clients.

Shouldn’t each node serve 3 clients when the option max clients is set to 3?

[Tom Elliott]

@mp12 I still don’t understand.

Both nodes only have a max of three clients?

[mp12]

Yes both nodes have a max of three clients!

Deploy of six clients is split into four and two on the nodes.

[Tom Elliott]

@mp12 i don’t know then.

[Wayne Workman]

@mp12 are you using the location plugin?

[mp12]

Am I missunderstanding the storage managment?

From FOG Wiki:
Each storage node has a setting Max Clients making this the maximum number of hosts that this node can image to

In my config each node should image to thrree clients.

[mp12]

@Wayne-Workman plugins are disabled.

[Wayne Workman]

@mp12 Can you set one node to zero and the other to 1 and see what happens when you deploy two? Then swap the 1 for 0, and then one that was previously set to 0, set that to 1. Then try again with two host imaging tasks and see what happens?

Right now - it’s clear there is some sort of issue, but knowing how it behaves in various conditions will help us locate exactly where the issue is.

[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.