Compile and Running CTA in Alma9 Linux

To be able to migrate CTA from Centos7 to Alma9 Linux we should to complete some steps before:

1. Compile CTA in Alma9 Linux
2. Running those generated RPMs in the CI passing the test

added Building and Packaging Continuous Integration labels

assigned to @jcamarer

created branch 499-compile-and-running-cta-in-alma9-linux to address this issue

mentioned in merge request !357 (merged)

added Needs Discussion label

To be discussed when we need this completed

mentioned in issue #266

marked this issue as blocking #266

Problem with Oracle. Occi library is compiled partially with ABI=0. I've tried some workaround, but it doesn't work properly. Also another errors:

Aborting: create failed: createConn failed: ORA-24960: the attribute  OCI_ATTR_USERNAME is greater than the maximum allowable length of 255

The library doesn't work properly.

JSON precision,

In test we have:

  JSONCTestObject to;
  to.double_number = 42.234567;
  to.integer_number = 42;
  to.str = "forty two";

  ASSERT_EQ("{\"integer_number\":42,\"str\":\"forty two\",\"double_number\":42.234567}",to.getJSON());

But gtest give us this error:

/home/cta/CTA/common/json/test/JSONCObjectTest.cpp:33: Failure
Expected equality of these values:
  "{\"integer_number\":42,\"str\":\"forty two\",\"double_number\":42.234567}"
  to.getJSON()
    Which is: "{\"integer_number\":42,\"str\":\"forty two\",\"double_number\":42.234566999999998}"

In Centos7 we didn't have that loose of precision. The number was the same. Is it acceptable?

One place where this will be kind of important will be the new log format in the timestamp (see #488 (closed)): "time":"1694677443.123456789" we should not have multiple log lines with the same message colliding on the timestamp because of the double rounding.

Same issues there:

Alma9:

echo '{"t": 1694677443.123456789}' | jq .
{
  "t": 1694677443.123456789
}

CC7:

[jleduc@ctaproductionfrontend02 /]$ echo '{"t": 1694677443.123456789}' | jq .
{
  "t": 1694677443.1234567
}

Non json native types uint64, double,... are not really deterministic.

For JSONCObject is used by:

• disk/JSONFreeSpace.hpp
• disk/JSONDiskSystem.hpp
• cmdline/standalone_cli_tools/eos_namespace_injection/MetaData.hpp
• cmdline/standalone_cli_tools/change_storage_class/JsonFileData.hpp

But they are not using double values.

It seems that json-c is already aware of this problem, at least since v0.12. Could we maybe just use this mechanism to fix this problem? https://json-c.github.io/json-c/json-c-0.12/doc/html/json__object_8h.html#a50c188c8eb9007f05ab1aa0e22eae90c

changed iteration to EOY 2023 targets Nov 21, 2023 - Dec 22, 2023

Issue to get the correct version of libocci library:

https://cern.service-now.com/service-portal?id=ticket&table=u_request_fulfillment&n=RQF2473364

They told me this:

Related to RQF2473364 that Nilo helped you with. If your system is puppet managed, take a look at https://gitlab.cern.ch/ai/it-puppet-module-cernoracle - it's a puppet module adding all necessary repos for Oracle client and tnsnames file.

closed

reopened

marked this issue as related to #567 (closed)

mentioned in issue #567 (closed)

marked this issue as related to #334 (closed)

mentioned in issue #334 (closed)

I fixed the tape REST API tests in https://gitlab.cern.ch/cta/CTA/-/jobs/35531508

The strategy here was to disable the certificate check in CI tests if the container is Alma: WARNING: Certificate checks are disabled in this test.

The certificate generation script was adapted from EOS CI but it has not been ported yet to Alma9.

This is an independent issue that should not be on the critical path for Alma9 compilation. Indeed we know how to get some valid host certificates in production, but this is a bit trickier in CI closed environment.

added priorityhigh label

closed with merge request !357 (merged)