CERN plan to upgrade from SL7/CentOS7

22

Thanks for all this very usefull info Joao.

So, if I understood correctly

  • You will test EOS5 version that is later then 5.1.29 and, if stable, you will
    deploy it on your production instances
  • This EOS5 version of choice will accompany the next CTA4/CTA5 public release (again assuming that the combination has been tested successfully)

My question: This new EOS5 version will be deployed in prod with the next public release of CTA4 or CTA5?

Best,

George

23

Hi George,

Yes, that is correct.

About your last question, we first plan to deploy EOS5 in all instances, before moving CTA4 to CTA5.
CTA4 can work well with EOS5.

The only difference of CTA5 is that it uses XRootD5 instead of XRootD4. Besides this they are both exactly the same.

Best,
Joao

24

Hi George,

Here is an update:

Now that the Heavy Ion run is over, we have started upgrading our EOSCTA production instances to EOS 5.1.28. This is a rolling update over all our instances and we expect to be finished by end of November.

Due to the issues with EOS 5.1.29, we decided to go back one version to 5.1.28 for this upgrade campaign. Once we are done, we will upgrade again to a newer EOS version, which is a more lightweight procedure than the EOS 4→5 upgrade.

CTA is still v4 for the time being, we plan to upgrade to v5 once EOS 5 upgrades are done. There will be a new CTA public release early in the new year.

Cheers,

Michael

25

Hi Michael,

Many thanks for the update.

Following you, we will also upgrade to EOS 5.1.28.

On CTA, we are still on 4.8.7 so I think it would make sense to upgrade to the latest public release (4.10.0-2) as we will upgrade to EOS 5.1.28 - of course we will test this combination. Please let me know if you think this doesnt make semnse.

Best,

George

26

Hi George,
this makes sense: here are the combinations we used in production: eos 4.8.103/5.1.28 + cta 4.10.0-2.

EOS 4 to 5 checklist should be checked on the eos side as this implies removal of mq and some leveldb to extended attribute conversion on FST (this is not a big deal eoscta disks are usually almost empty).

So I would upgrade cta before upgrading to EOS5.

Cheers,
Julien

27

Hi Julien,

Thanks a lot for confirming.

Where about is the EOS 4 to 5 checklist?

Best,

George

28

Dear George,

below please find a link to a pdf checklist used within
CERN for the upgrade from EOS 4 to EOS 5:

https://cernbox.cern.ch/s/qj5NEXzrIXqOFQZ

Please let me know if this works fine for you.

Best,
Jaroslav

29

Hi Jaroslav,

Many thanks for the link. I went through the document and I have a few questions:

  • In our config management system, we have a variable called EOS_XROOTD_VERSION which up to now was set to ‘4.12.8-1’, the xrootd version in the citrine deps repo and which was the same with version of the eos-xrootd package. In EOS5, this is no longer the case: the highest xrootd version in the diopside deps repo (5.2.0-1) is not the same with the highest version of the eos-xrootd package (5.6.2-1). So, which one should I choose?

  • I understand that I need to remove the eos-scitokens package but I can see no scitokens-cpp in the diopside deps repo.

  • I need to remove the installed quarkdb-0.4.2-1.el7.cern.x86_64 before installing /eos-quarkdb-5.1.28-1.el7.cern.x86_64. right?

George

30

Hi George,

I already replied to your first point on the EOS Community forum.

eos-scitokens was a repackaging and an extension of the basic XrdSciTokens library. We now use the base functionality that comes from XRootD. The scitokens-cpp comes from EPEL and is not related to eos-scitokens.

For QuarkDB there are no more separate packages, quarkdb is now released as part of EOS. There is a new eos-quarkdb package that contains the required library for quarkdb. The new eos-quarkdb obsoletes the old quarkdb package so it will be removed automatically.

Cheers,
Elvin

31

Hi @jleduc,

Just to confirm: In the case where you have upgraded to EOS 5.1.28, you are keeping the EOS4 eos-client package (4.8.105) on your frontend and tape servers, right?

You must be but just a sanity check.

George

32

Hi George,
exactly: I think it makes more sense to stay with eos4/xrootd4 on the common part until all EOS instances have been upgraded to EOS5.
CTA will be upgraded to version 5 once all eoscta instances have been upgraded to EOS5.
I think it would even make more sense to entirely remove eos client commands from the frontends and tape servers: standard operations procedure should not run eos commands from CTA side or cta-admin commands from EOS side.

Julien

33

HI Julien,

Many thanks for the confirmation. I will ago ahea with upgrading our dev and preprod instances and get back if I run into any problems.

George