The current release of EOS is 4.7.15, however in the el-7 tag repo the latest version I can find is 4.7.7. Also there is no el-8 repo (in tag) yet, which I would like to move to eventually.
In comparison, the “commit” repos contain both v4.7.15 packages and an el-8 repo.
The repos mentioned are the one below here: https://storage-ci.web.cern.ch/storage-ci/eos/citrine/
I’m not sure if I’m missing something here, or the builds are just not in the tag/el-7 repo yet.
Please look at the repos here: https://storage-ci.web.cern.ch/storage-ci/eos/citrine/tag/testing/
These are the packages from the latest tag releases. This is in general what we run at CERN. From time to time to promote a certain versinon to the ‘stable’ repos. That is why these are called ‘testing’ but they are the most up to date.
Hi,
Thanks for the reply.
We’ve switched the repo and are using EOS v4.8.4 now.
One thing we noticed for fusex mounts: we get an “too many redirects” error on the clients, when we use the DNS round-robin entry that contains all 3 mgm (the eos cli client handles this correctly, it’s only fusex).
If we set the currently active mgm master node, the mount and filesystem access works fine. Is there a better solution for this - otherwise the fusex won’t handle mgm master failover correctly.
We recently had a discussion about this with the XRootD developers and the hope is that in the future the XRootD client will “stick” to the given master rather when trying “blindly” all the hosts behind the alias. This currently not in place therefore, you need to have you DN alias always pointing at the current master. You either do this manually or you add a monitoring script that is capable of changing the alias to always point to the current master.
You can query the status of an MGM using the following command: xrdfs root://eosbackup-ns-01.cern.ch// query opaquefile /?mgm.pcmd=is_master
Also, a round-robin DNS alias is not such a good idea since it introduces unnecessary redirections and delays.