Snapins loose storage groups going from FOG 1.1.2 to 1.3.0 RC-8

[ablohowiak]

With the release candidates, if you have a storage node down, but still enabled it’s impossible to edit or create a snapin. The page will eventually timeout and will be blank.

The apache log will have the offending storage node, and once the storage node is disabled snapins are able to be created and editted.

I’m assuming this is because of the snapin replication feature. Just wondering if this could be improved somehow?

Thank you.

[Tom Elliott]

They don’t lose storage groups going from 1.1.2 to 1.3.0 (any rc you want).

They don’t lose storage groups going from and version 1.2.0 and earlier because Storage Groups for snapins didn’t exist at all.

Trunk introduced the idea that snapins work in a similar fashion as images and because of this should be allowed to replicate and move around to different groups and nodes.

So it’s no surprise they don’t have group settings defined. This is because we don’t know (we being the FOG team) how you intend to use your snapins and think it’s safer to allow you to setup how you need it setup.

Please define your relevant storage groups and reupload the files as needed. This should fix the storage group problem for you too.

[Wayne Workman]

How is your snapin’s Storage Groups setting configured? How many storage groups do you have? How many master nodes?

[ablohowiak]

@Wayne-Workman

I guess upgrading from 1.12 might have left old snapins blank.

All snapins are only on the master node.

[Wayne Workman]

@ablohowiak Alerting @Tom-Elliott to this, and moving to bug reports.

I do apologize. However - if you are willing, there should be a backup of your old database on your fog server in /home

If you could email this to Tom, he can figure out why this happened. Don’t post the file here, it has sensitive data in it.

Also, moving to bug reports for the moment - and re-titling the thread to something more appropriate.

[ablohowiak]

@Wayne-Workman
This system has gone through multiple updates, I don’t recall when exactly this started to happened, and I know I’ve upgraded it since then. I’ll be fine fixing it myself, if all that’s needed is to repopulate the primary storage group.

[Wayne Workman]

@ablohowiak said in Snapins loose storage groups going from FOG 1.1.2 to 1.3.0 RC-8:

This system has gone through multiple updates, I don’t recall when exactly this started to happened, and I know I’ve upgraded it since then.

That is a vital piece of information that we needed to know earlier. So, there is probably absolutely nothing wrong with Release Candidate 8 in regards to the OP, and your setup was broke from before.

[ablohowiak]

@Wayne-Workman
No, I noticed these symptoms earlier, and given it has specific conditions to happen, there’s no way to pinpoint when or what caused it. When looking at the list of snapins the storage has a value, which is different from looking at the individual snapin.

[Wayne Workman]

@Tom-Elliott what do you think?

[Tom Elliott]

They don’t lose storage groups going from 1.1.2 to 1.3.0 (any rc you want).

They don’t lose storage groups going from and version 1.2.0 and earlier because Storage Groups for snapins didn’t exist at all.

Trunk introduced the idea that snapins work in a similar fashion as images and because of this should be allowed to replicate and move around to different groups and nodes.

So it’s no surprise they don’t have group settings defined. This is because we don’t know (we being the FOG team) how you intend to use your snapins and think it’s safer to allow you to setup how you need it setup.

Please define your relevant storage groups and reupload the files as needed. This should fix the storage group problem for you too.