That seems to have fixed the issue. I ran two images successfully.

Thanks.

@tom-elliott said in Fog 1.5.2 ignores image storage group association:

Are you saying the image is not assigned to the storage group it’s attempting to pull the image from?

Yes, that’s exactly what’s happening.

I’m open to it being a configuration issue but I don’t know where it is. If you need troubleshooting information from my system let me know and I’ll post it.

My storage nodes are setup

The image’s storage node assignment

Here’s what the task’s page looks like before the client checks in. The correct node is in the working with node column.

This is what happens when the client checks in, the working with node changes to one that isn’t associated with the image.

I updated to the working branch this morning. It shows the version as 1.5.2.5 now. Still doing the same thing.

I don’t have the location plugin installed.

One thing I did notice while I was testing it this morning is in the task view the working with node column shows the correct node until the client connects.

The workflow was:
Create task.
Check Active Tasks, Working with node is correct.
Boot client into fog.
Client Checks in.
Check Active Tasks, Working with node has changed to incorrect node.
Client fails because the image doesn’t exist on that node.

A little background. I have three storage groups setup in our environment, one for our main campus and one at each of our two satellite campuses. The fog server resides on our main campus and there is a storage nodes at each satellite. Each storage node is in a separate group. It’s setup this way because there are images we don’t want to replicate to the satellite campuses and to conserve bandwidth across the wan.

campus | storage group | server
main | sg1 | fog
sat1 | sg2 | storage1
sat2 | sg3 | storage2

Everything had been working fine in 1.4. We just updated to 1.5.2 to start testing for our next deployment and I’m running into an issue.

When I deploy an image that’s only associated with our main campus image group it will sometimes use one of the storage servers that are in a different storage group. This happens with any image I try. I’ve deleted and recreated the image definition and still the same behavior. It seems that it is randomly picking a storage server regardless of whether the image is associated with it’s storage group or not.

Thanks for putting this together. It’s a lot less kludgy than the boot drive’s I’d made for clients that don’t support pxe boot. I did run into one tiny issue with your script. I’m running centos 7, but this shoud apply to anyone running bash. The
cat > /mnt/boot/grub2/grub.cfg << EOF command will evaluate all of the variables in the grub script instead of writing them out literally. Putting single quotes around the EOF will tell it not to evaluate anything.

cat > /mnt/boot/grub2/grub.cfg << 'EOF'

Other wise all of the variables in the grub script are written out as empty strings.