Image doesn't replicate after updating to RC19

[moses]

Server

• FOG Version: 1.3.0-RC-19
• OS: Centos 7

Description

After updating all my nodes and database server to RC 19, a newly created image (created after the update), doesn’t replicate. Replication is turned on for the image, and I have another node listed where it should be copying to. The replicator log only lists this:

[11-04-16 4:01:37 pm]  | Not syncing Image: W7P-Universal-x64-STANDARD
[11-04-16 4:01:37 pm]  | This is not the primary group.

But it is the primary group!

It should be replicated from the database server on the “HQ” group to another master storage group node in another group.

Any ideas?

[Tom Elliott]

This is now fixed for RC-21. (RC-21 has not been released yet.)

it addresses a few different things.

For sure, now, it address the set primary setting. Fix for it was to scan which group (if any) is set as primary. and reset it if it was after applying our settings to the image/snapin.

yes, this exact same error would’ve shown up for the snapins as well.

[Tom Elliott]

Go into the storage group area and check the box for the group that is your primary master. Enjoy as the image starts to replicate.

[moses]

@Tom-Elliott When I do that and save the changes, the checkbox disappears. Probably should have mentioned that, but since it was listed on the side (in the screenshot), I thought the UI had changed slightly.

[moses]

@moses Nothing of use is showing in the PHP logs, but mysql shows that value is left at null (last entry):

+-------+------------+-------------------+------------+
| igaID | igaImageID | igaStorageGroupID | igaPrimary |
+-------+------------+-------------------+------------+
|    23 |          4 |                 1 |          0 |
|    57 |         10 |                 2 |          0 |
|    58 |         10 |                 1 |          0 |
|    68 |         10 |                 7 |          1 |
|    71 |         10 |                 8 |          0 |
|    70 |          4 |                 7 |          1 |
|    75 |         10 |                 9 |          0 |
|    77 |         10 |                10 |          0 |
|    79 |          4 |                 8 |          0 |
|    80 |          4 |                 9 |          0 |
|    81 |          4 |                10 |          0 |
|   103 |         17 |                10 |          0 |
|   114 |         17 |                 7 |       NULL |
+-------+------------+-------------------+------------+

Changing it manually to a 1 fixes the issue and replication starts, but still can’t update it using the UI.

[Tom Elliott]

Please run:

ALTER TABLE `imageGroupAssoc` CHANGE `igaPrimary` `igaPrimary` ENUM('0','1') NOT NULL;

And update the field again?

[moses]

@Tom-Elliott See the bottom of my post below; changing it manually worked and replication starts, however can’t change it in the webgui. If you need any specific logs on that let me know.

[Tom Elliott]

@moses The code that handles it is working from what I can see.

[Tom Elliott]

@moses I ask you to run the code to ensure it gets loaded up and updates as appropriate ( a null value should not be allowed at all ). Then try in the GUI.

[Tom Elliott]

I’ve updated the schema files to at least define the is primary portions for images and snapins to use the enum allowing only 0 and 1 as the entries here. I’ve also added the equivalent alter flags for these fields as well to ensure those without it will be updated.

I doubt, however, that this will fix the issue though it could. The original entry only allowed a tiny integer having a max character length of 1 ( 0 - 9). It is strangely odd that the is primary field was not being set properly for you while I could see it fine.

[moses]

@Tom-Elliott Unfortunately, I can’t change it the GUI still. It doesn’t change from a 0.

Worse still, I can’t change it manually in the DB:

I’m using:

UPDATE imageGroupAssoc SET igaPrimary = 1 WHERE igaID = 118;

It now results in:

Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

The table is here:

 +-------+------------+-------------------+------------+
| igaID | igaImageID | igaStorageGroupID | igaPrimary |
+-------+------------+-------------------+------------+
|    23 |          4 |                 1 | 0          |
|    57 |         10 |                 2 | 0          |
|    58 |         10 |                 1 | 0          |
|    68 |         10 |                 7 | 1          |
|    71 |         10 |                 8 | 0          |
|    70 |          4 |                 7 | 1          |
|    75 |         10 |                 9 | 0          |
|    77 |         10 |                10 | 0          |
|    79 |          4 |                 8 | 0          |
|    80 |          4 |                 9 | 0          |
|    81 |          4 |                10 | 0          |
|   103 |         17 |                10 | 0          |
|   118 |         17 |                 7 | 0          |
+-------+------------+-------------------+------------+
13 rows in set (0.01 sec)

Is my query correct? This issue only appears to happen with this image, so if I can set it correctly manually I’ll just ignore it from here on.

[Tom Elliott]

@moses Your query is correct, except it’s now an ENUM not an integer. The ENUm is a string value.

Try:

UPDATE imageGroupAssoc SET igaPrimary = '1' WHERE igaID = 118;

[Wayne Workman]

Cross-linking similar threads:
https://forums.fogproject.org/topic/8911/can-t-set-image-s-primary-group
https://forums.fogproject.org/topic/8899/image-doesn-t-replicate-after-updating-to-rc19

[moses]

@Tom-Elliott Ah, yes, didn’t look at the value type, thought it was an integer. That worked.

As I said, I’ll personally just ignore this for now, since this only seems to be a problem with this particular image. You can mark it as solved if you want, or track it if the other posts Wayne referenced are relevant/needs further investigation. I can provide any logs/info you might need if you want to look into it further.

If it matters, I updated this morning to RC20 and the issue persists.

[Tom Elliott]

This is now fixed for RC-21. (RC-21 has not been released yet.)

it addresses a few different things.

For sure, now, it address the set primary setting. Fix for it was to scan which group (if any) is set as primary. and reset it if it was after applying our settings to the image/snapin.

yes, this exact same error would’ve shown up for the snapins as well.

[moses]

@Tom-Elliott You’re the man, Tom!