I am trying (on a test platform) the latest version eos-4.5.6 that was published in the Citrine stable repo on September 2nd.
I noticed that there is a new package eos-xroot that was introduced in citrine-depend earlier this year.
I suppose it bring the right version of xrootd to EOS, but does this mean that one should remove the other xrootd packages from an EOS server ?
What about the dependency on libmicrohttpd-0.9.38-eos.yves.el7.cern.x86_64 that existed before, has it been remove and can this package be removed ?
Yes, the eos-xrootd package will install the required xrootd version for eos in /opt/eos/xrootd/. It’s up to you if you want to remove the system xrootd packages - these will not be used by eos if the eos-xrootd package is installed.
The libmicrohttpd dependency remains unchanged.
Thank you Elvin,
I dared performing the update “live” with all eos services running and what I see is that:
I still have previous xrootd processes running (sync,mq,fst,mgm) in parallel with the new /opt/xrrotd processes, I do not know how harmful this can be in prod. It is easy to stop all eos xrootd based services before the update but one should be aware of it.
I noticed also that quarkdb is still based on the standard xrootd, this means I cannot remove it until configuration is reviewed to be based on the eos-xrootd (if this is the way to go)
QuarkDB will remain dependent on standard xrootd packages, there’s no plan to base on eos-xrootd.
QDB makes very limited use xrootd features, in contrast to EOS, so there’s no reason to pin the version of xrootd used - the standard packages are always fine to use.
Yes, indeed one would also need to change the path to the xrdcp executable in the xrd.cf.fst file. This executable is not used per se for the TPC transfers but it is used by the XRootD daemon to advertise that it supports TPC transfers.
As far as compatibility between versions goes, for question 1) the answer is yes there was no change in the communication between slave and MGM. For question 2) it’s quite hard to give an answer as there have been quite some changes in preparation for dropping the MQ daemon but in principle usual interaction should work fine.
Thank you Elvin,
As for 2), I am going to prepare everything in order to be able to quickly update EOS on the FST servers in case communication is not all right. I suppose that this is sth I would discover at the moment I attempt the transition to having the updated manager becoming master. In this case, reverting the role exchange would (hopefully) restore the cluster’s operations… (?)
JM
Today I updated the slave EOS manager to eos-4.5.6, then performed a role exchange and updated the other manager that had become the new slave. Everything fine, minor annoyments with the synchronization of the namespace files, but I figured out how to make things work.
Now updating the servers, I notice that the dependency on eos-xrootd that has been added to the eos-server package on EL7 is not in the eos-server package in EL6. This might be a bug.