Image Capture Issues

[jburleson]

OS: Ubuntu 16.04
Fog:
Running Version 8515
SVN Revision: 5882

After capturing an image, I can no longer click on the image link from the image list to edit it or view information about it. This is due to the storage group no longer being associated with the image.

Prior to image capture, the image was associated with a storage node. After capture, the storage group was remove. I tested this on two different images and it happened both times.

Database table imageGroupAssoc before capture

*************************** 2. row ***************************
            igaID: 2
       igaImageID: 34
igaStorageGroupID: 1
       igaPrimary: NULL

Database table imageGroupAssoc after capture

*************************** 2. row ***************************
            igaID: 10
       igaImageID: 34
igaStorageGroupID: 0
       igaPrimary: 0

Note that the igaStorageGroupID has changed from 1 to 0. Switching the igaStorageGroupID back to 1 fixes the problem.

After capturing an image, the owner of the captured image directory is changed from ‘fog’ to ‘root’.

Prior to capture

drwxrwxrwx  2 fog root 4.0K Jul 6 11:05 OptiplexD1D4Fall2015

After capture

drwxrwxrwx  2 root root 4.0K Jul 12 09:58 OptiplexD1D4Fall2015

[Wayne Workman]

Issue confirmed on trunk 8529 @Tom-Elliott, When I clicked list all images - everything completely stopped working

No PXE booting, no web interface.

[Wayne Workman]

My post was a false alarm - turns out the fog server was just under a really, really heavy load.

There were 4 sites each imaging 3 computers, a large snapin was being replicated to 14 servers, a large image was being replicated to 14 servers, and there was an image upload going and there were 53 hosts queued for image deployment each sending a progress report poll every 3 seconds…

Fog server was very busy. It’s settling down now a little.

[jburleson]

When I captured the image a second time, it did not change the storage group id. The filesystem owner did change back to root, but that may not be an issue since ‘other’ has rwx permissions.

This may be in someway related to my migration from 0.32 to trunk as it only seems to affect my old images.

[Tom Elliott]

@jburleson I still have your db, so I’ll see if I can find the issue myself. I think you may be correct though. It’s updating the storage groups, but the info got double inserted, likely from one point where the image had not had an image group associated (so there’s probably two entries for these image groups) one that has a valid storage group/image id assocation and one with an invalid.

[Tom Elliott]

I have not had enough time quite yet to test this fully, but I’ve also not been able to replicate either. To test, i registered one of my vm’s. I then took one of the pre-existing images and associated it with that new host. Then I asked it to upload. I did not see it change the storageGroupID to 0. Of course I still need to test a few other things, but I also didn’t see any duplicate image information within the imageGroupAssoc table…

[jburleson]

@Tom-Elliott I think we can mark this as a one off problem. Maybe I missed a step when I migrated the old images. Thanks for looking into it.