Not 100% sure if this is a “bug report” or not, and not sure how to even write this one out as I like to provide as much info as possible but…
I’m having the darndest time getting a fog client to TFTP boot (and more importantly, pull down the image itself locally) consistently from a storage node in a remote subnet. Sometimes boot.php on the master install will direct clients to image from the local storage node which is 100% the desired behavior, and sometimes boot.php will direct the client to pull down bzimage etc from the master server.
On each storage node, I am replacing the storage node IP in the chain line of /tftpboot/default.ipxe with the IP of the master install. This is per some documentation I read once upon a time for an older version of fog, and it’s worked fine up until recently.
Poking around the database in the location table, I’m noting that the lTftpEnabled column entries all contain o (as in lowercase orange, not zero) for locations that appear as TFTP Boot Enabled in the GUI, rather than 1 which is what I would expect?
In fact, changing this “o” to any value at all appears to retain the TFTP Boot Enabled setting in the GUI. Changing this value to 0 does change TFTP Boot Enabled in the GUI to “unchecked” as one would expect. Unchecking it in the GUI and saving the change actually blanks out this field, rather than changing it to zero.
I don’t know if the databse oddity noted is relevant at all, but the expected behavior from my end is if the location is set for a host, then it needs to pull boot and image files strictly from that local tftp-enabled storage node.
Sorry if this is rambling. I’m having a difficult time nailing down problem duplication steps because it doesn’t seem to be acting consistently either way.