QuarkDB namespace supported on Scientific-Linux 6


I would like to be sure that the migration to the new QuarkDB namespace is supported on SL6 and what is the minimum versions of EOS and xrootd to use.

In the case the QuarkDB namespace is not supported on SL6, I will be able to reinstall the managers
(currently 2 in master/slave) in CentOS7 but I would like to avoid or at least delay the reinstallation of all dis servers in CentOS7. The question is thus : Can I have managers in CentOS7 dealing with diskservers still in SL6 (with homogenious versions of EOS and xrootd) ?

Thank you


Hi Jean Michel,

Yes, it’s possible to keep MGM + FSTs on SL6 when using the new namespace.

Currently, QuarkDB is not being built on SL6, but only on CC7 - so for the QuarkDB nodes themselves, it’s recommended to use CC7.

Yes, it’s also possible to have the MGM on CC7, and FSTs on SL6 and upgrade the OS on a rolling basis.

If you have a pressing need for SL6, I could also start building QuarkDB packages for SL6, but we’d rather avoid it if possible, as we’d prefer people to start moving to CC7.


Regarding which versions to use, the current recommendation would be:

  • eos 4.4.23 along with xrootd 4.8.4 is known to be a stable combination, we have several production instances on these versions.
  • Any version of QuarkDB higher than 0.3.2, but prefer the latest one. (currently 0.3.5)

(The above recommendations are of course subject to change, as newer versions are being released and tested)


Thank you Georgios,

I am planning but not ready to do it tomorrow. Thanks for the versions, I understand that it may change if I take too long to bite the bullet.

If EOS on SL6 and on CentOS7 can interoperate, I suppose the best would be to reinstall both managers to CentOS7 one after the other (rolling upgrade), updating EOS to 4.4.23 at least and prepare QuarkDB on these nodes. Then I would be ready to migrate the namespace but:

  1. I would need a third QuarkDB server (in CentOS7) in order to reach the quorum of 3. I could not (yet) use a disk server since they would still all be in SL6, right ?
  2. … and BTW: I suppose there is no problem for managers in C7 with EOS 4.4.23 to talk to EOS 4.2.25 on SL6 diskservers ?

Later on when replacing disk servers, I would install the new ones in CentOS7, possibly use the new empty servers to drain older ones and reinstall them in C7 too.


No problem for a C7 EOS manager to talk to a SL6 EOS manager (master/slave) with same EOS version ?

Even if they stay in SL6, EOS servers can be updated to version 4.4.23, that is the same as on managers.


Hi Jean Michel,

  1. Indeed, QuarkDB is not being built on SL6 right now. You could upgrade the MGMs + 1 FST to reach a quorum of three. Note that it’s possible to run QuarkDB on 2, or even 1 node (there won’t be high availability), and add a third one later on. (to enable high availability) There’s also the possibility to start building QuarkDB on SL6, if that makes life easier for you.

  2. Yes, this should work (although we haven’t tested this combination specifically), but it’d be a good idea not to stay like that for a long time, and do a rolling upgrade of the FSTs as soon as the MGM upgrade is finished. You could upgrade the diskservers to CC7 at a later time, that’s fine, but personally I’d feel more comfortable if the MGM and FST versions were close. (4.4.23 and 4.2.25 are 9 months apart)

Not a problem.

Yes, that’s much more desirable than having the MGM and FST versions diverge too much.