Possible Image and Snapin Replication Problem w/ Working Branch

[Wayne Workman]

@jim-graczyk lots of FTP errors. I’d say check your FTP credentials to be sure they are correct. There’s a test here you can do: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP#Try_to_get_a_file_with_Windows:

[Jim Graczyk]

@wayne-workman

I’m thinking the FTP errors are the result of failed replication, not the cause - again, but what do I know…
I’m thinking this only because the FTP errors are from FOG client machines attempting to access a snapin that hasn’t replicated.

I’ll test the FTP connection of each node for files I know are actually on each node and report back…

Jim

[Jim Graczyk]

@wayne-workman

I was able to connect to each node’s FTP service with the credentials stored in the storage definition in FOG and transfer files into and out of each server.

Jim

[Wayne Workman]

@jim-graczyk I’m looking through the recent commits to the working branch of FogProject: https://github.com/FOGProject/fogproject/commits/working

Tom did push a comment to correct issues with replication in there. So what I’d recommend is updating to the working branch to see if it’s fixed or not.

If you’re unfamiliar with how to switch branches and update, go to your git repo location on your servers (each server needs done). Do this first:
git pull
Then this:
git checkout working
then the usual:
cd bin
./installfog.sh -y

[Jim Graczyk]

@wayne-workman All nodes are already up-to-date (as reported by git pull). We had updated to v24 at 10 am this morning and retested replication before posting this issue to the forum.

Jim

[Wayne Workman]

@jim-graczyk Ok then. I think you’ve found an issue with replication in RC8/working. Without waiting for the developers, you have two options. 1 is to go back to RC 7 where it worked. 2 is to just manually scp the image & snapin changes to the nodes as appropriate and see if that works.

Here’s how to go back to rc7:

git checkout 31a61db2c12ebc394ea167f9b37ba6ef4da7ea99
cd bin
./installfog.sh -y

Normally I don’t recommend downgrading but it looks like no DB changes have happened since then and now, so it should work in this case. (future readers, it will not work for you).

When our developers come back from vacation, hopefully they can resolve the issue.

AND - I feel it’s time to build some quality-checking for replication - so I’ll be working on that in my free time in the coming weekends so that we can immediately know when this stuff isn’t working in one of the branches.

[Jim Graczyk]

@wayne-workman

I prefer to move forward rather than backward so I’ll choose Option B - manually replicate and test that it’s only a replication problem. We’re already working on that. This will work for a few days, but we’ll have problems as soon as we have to upload PCs before imaging.

I’ll post here if all images and snapins work to clients at each site.

Jim

[Tom Elliott]

@wayne-workman while quality assurance is always a good thing, the code I added would not have broken what is being reported here. I added a simple check to find out if it can reach the server on port 21, the ftp port. If it cannot communicate it will report it cannot. If it does communicate it will perform replication tasks.

[Jim Graczyk]

@tom-elliott

thanks Tom… we’ve tested FTP and found it working on all nodes…

Jim

[Sebastian Roth]

@Moderators @Testers Is anyone able to replicate this issue?

[Wayne Workman]

@sebastian-roth I have plans (in my head) to build automated functional testing for this, I’m not setup to test replication at the moment.

[Jim Graczyk]

I just wanted to let the FOG team know that I have just completed the build of a new FOG server using v1.5.0 RC9, Dev Branch, with associated storage nodes. We created storage groups and storage nodes, after uploading images. Installed the Locations Plugin and set locations. We moved our images and snapins to the new FOG installation…

And we’ve reproduced the same problem we’ve had on FOG system on which this original posting was based. We have no replication of images or snapin, even though the storage nodes are working as expected.

We’ve written a bash script to replicate both snapins and images from the main fog server to the storage nodes, so our installation works, but based on my experience, it’s very easy to reproduce this replications problem - just do an installation on fresh servera and the problems ensue.

Thanks,

Jim

[Tom Elliott]

@jim-graczyk Can you try on working branch please? There was an issue with implementation of finding “isAvailable” nodes which I’m pretty sure has been corrected for.

[Jim Graczyk]

@tom-elliott

Tom,

I’m using the working branch on my lab set up. I’ll pull it there.

I’m also OK trying the working branch on my new installation, as long as I can switch back to the Dev branch after pulling the current Working version.

Is it just a matter of changing the git checkout back to dev branch?

FYI - My new installation is showing SVN 6079 while the lab is showing SVN 6080 - if that helps any.

thanks,

Jim

[Tom Elliott]

@jim-graczyk Switching to dev-branch is as easy as git checkout dev-branch (re-run installer of course too).

However, reinstalling would put it back into state where it isn’t working properly again. I don’t expect the current working to remain working for too much longer though. Probably by end of this week I’ll make it into RC-10.

[Jim Graczyk]

@tom-elliott

Updated Lab to v52. Can no longer check replications logs.

Fog Configuration / Log Viewer gives me a Files: pulldown that is now empty.

Jim

[Jim Graczyk]

[Tom Elliott]

@jim-graczyk I’ll fix that later. Sorry that’s a missed thing in jquery call. The logs are still ‘working’, you just can’t view them currently from the GUI.

[Sebastian Roth]

@Jim-Graczyk Try less /opt/fog/log/fogreplicator.log on the FOG server command line.

[Tom Elliott]

Working should fix the GUI not displaying the logs for you now too.