Storage group association again - upload mode



  • Hi Tom,

    I confirm that this issue is solved:

    Re : Fog 1.5.2 ignores image storage group association

    But only in imaging mode.
    When uploading an image, “Working with node” column is always default, and image is really uploaded on default node.
    Image storage node assignment is ignored.

    Fog Version: 1.5.2.10 on all nodes



  • I forgot to precise version: 1.5.2.31



  • @tom-elliott
    After doing the same tests, this time everything is ok.
    Thanx


  • Senior Developer

    Found and fixed in working.

    The problem was whenever you removed a node from an image (regardless of primary status – primary status appeared to work properly if all you did was add and update). It would remove all group associations attached to that group ID. I just had a bad logic check, sorry for that.

    Fixed the logic check and found there was one other potential for issue and was able to address that as well. Tested a few different times and all appears to be working properly now, in regards to all things associated with this thread. (Capture node not following properly, and then deleting all images that had that storage group id associated to it).

    Please give an update and test, a real world test would be better than my basic testing/checks available.


  • Senior Developer

    @jgallo replication stops for any type of replication



  • I noticed after tinkering with the web UI images settings that if you configure the image and uncheck replication then also set the storage group to any other one than default it will not rename the storage groups for other images provided you do not try to remove default from within that storage group. What I’m not sure of is if you have multiple storage nodes in a storage group if that replication setting will not allow the image to replicate to those storage nodes in that particular storage group now if it’s unchecked.



  • I don’t know if this issue is linked to the initial one, but now capture and deply, in unicast mode or in multicast mode, are working fine.
    So, initial issue can be marked as solved.

    Maybe should I open a new subject, but , when my image storage group association is like this:

    0_1526996712464_fog01.png

    My images storage association are ok:

    0_1526997107272_fog03.png

    And I want to remove default one because I have only one storage group for an image.
    So I select it and delete it:

    0_1526997127242_fog02.png

    And now all images but the one I modified are linked to default storage group.

    0_1526997182902_fog04.png

    An finally, if it can help, I could see that just after modifiyng storage group in image association, I had only one line in database table, the one I was modifing.
    The others came after, with 1 and 1 in IgaStoragegroupId and igaprimary

    So I think that imageGroupAssoc table is dropped when asking to modify one image, and settings of other images are lost.



  • Ooops, I replied too fast. Not solved !!!
    My storage group association is again default for all my images.
    I’ll try again several tests to see after which one I can replicate this issue.



  • @tom-elliott
    In my previous post I meant that in Fog gui, list all images, in “storage group” column, all images was on default.
    And I verified in imageGroupAssoc table in database, IgaStoragegroupId and igaprimary were 1 and 1 for all lines.

    But now, this issue seems solved.
    I tried unicast deploy, capture, and multicast deploy, with Image storage group association = default + a primary node.
    Then I deleted default one in image storage group association, and I tried again same tests, so with only one storage group associated.

    And now all is fine.
    Thank you


  • Senior Developer

    I was able to somewhat replicate this issue and believe I have fixed it again. I did a very basic set of tests to confirm and test the fixes, so a realworld test would be very much appreciated.


  • Senior Developer

    @claude-girard what do you mean they all changed to the default group? The method I created doesn’t change any data at all, it checks the image association for the primary group, and uses that group to find the master of that group. I’m guessing by changing it, the GUI is still showing properly, just at capture/multicast tasks it’s always trying the default group?



  • Bad news.
    I saw that all my images were changed to default group and only this one, since upgrade to V 1.5.2.26

    So I think you should revert to previous code, before this fix.
    This issue is really annoying :-)



  • Finally, I had a few time today, and I tried 2 debug task, one in deploy mode, the other in capture mode.
    But I don’t know if it will help you.
    In first screen capture, deploy mode, IP address 172.20.40.16 is the good one.
    In second screen capture, in capture mode, IP address 172.20.165.12 is bad.

    I modified storage variable, replacing 172.20.165.12 by 172.20.40.16, and running fog.
    unfortunately, in fog interface, storage node was again the bad one.

    0_1526653999106_IMG_20180518_161042.jpg

    0_1526654081308_IMG_20180518_162210.jpg



  • Unfortunately no, I didn’t see any change after upgrade to V 1.5.2.26
    Worst, I discovered that the issue in deploy mode was there again, but in multicast.
    I didn’t try multicast deploy with previous versions, so I can’t say if this bug was already present.
    I’ll try different debug mode next week, to see if I can help you better.


  • Senior Developer

    @claude-girard I’m not quite sure how best to address, though I have pushed some code in the hopes that it may work out better.

    Essentially the method was returning the lowest group number (typically Default). I have added a new method to try to implicitly receive the primary group, and if it cannot then fall back to the lowest id’d storage group assigned.

    Mind pulling the working branch and installing it to see if this is addressed for you? Also just test deploy works as expected too? I didn’t change how that is being presented, but sometimes this old php code can be very finicky. (Maybe too often if you ask me).



  • I have tested again, first by downgrading Fog to 1.5.2 version.
    Then upgrading to 1.5.2.11 version.
    For both versions my image storage group is:

    0_1525189971596_v-all-image-nodes.png

    First V1.5.2:

    Capture mode: node is correct

    0_1525190044754_v1.5.2-capture.png

    Deploy mode: node is bad

    0_1525190120206_v1.5.2-deploy.png

    This issue was solved, so now with 1.5.2.11 version:

    Capture mode: node is bad

    0_1525190215822_v1.5.2.11-capture.png

    Deploy mode: node is correct

    0_1525190259962_v1.5.2.11-deploy.png



  • I have only one node by group like that:

    0_1524596930728_storage-nodes.png

    And my image file is associated with my group “MP”,

    0_1524596945876_image-storage-group.png

    When I deploy, image is read from correct node (mp-fog), but when I upload, same image is captured to default group, Defaultmember node.


  • Senior Developer

    Depends on what you mean. Image uploads are ALWAYS captured to the master node of the group their within. In the case of multiple groups being associated, the primary group master node will be the one the image is captured to.


Log in to reply
 

448
Online

6.3k
Users

13.7k
Topics

129.1k
Posts