Use RTI Connext 6.0.1 on Jammy and when building Rolling on Windows

[nuclearsandwich]

Installs RTI Connext 6.0.1 via debs on Linux.

• I updated the entry_point.sh script to source the rtisetenv script since there's "guessing" logic in rti_connext_dds_cmake_module which is looking for 5.3.1 and does not find 6.0.1.
• I'm not yet sure whether the .debs are able to be used for DDS security tests. should give us a hint. If they can, I'd propose that we make that the default and only installation method for 6.0.1 on Linux in order to remove some CI complexity.

For Windows I updated the private submodule to ship both 5.3.1 and 6.0.1 and updated the cookbook parameters to use 6.0.1 in Rolling. A build for that is being tested

Once we're through these initial builds I'll start full CI runs to verify that this doesn't break anything above it.

[clalancette]

One minor comment inline, but the code otherwise looks decent to me.

CI seems to be unhappy, though :(.

[clalancette]

Out of curiousity, is it actively harmful to source the 5.3.1 setup script? If not, I think it would be more consistent to just source it here (even if rti_connextdds_cmake_module may redo some work).

[nuclearsandwich]

Probably not. I was aiming for a minimal change. I think there's a fair bit of refactoring we could do to simplify the plumbing here if we take a step back and look.

[nuclearsandwich]

Oh! one minor speed bump is that we can't source the 5.3.1 script from a POSIX sh script without seding it first as we do in the release repository for connext_cmake_module (and which hasn't been ported to rti_connext_cmake_module due to the guessing behavior)

[clalancette]

That's fine, this isn't a blocking problem anyway. Just curious about it.

[nuclearsandwich]

• I'm not yet sure whether the .debs are able to be used for DDS security tests. should give us a hint.

Based on the test output it looks like the answer is no. That's a bummer. I'll have to look at getting the evaluation binaries installed on Linux as well.

[nuclearsandwich]

For Windows I updated the private submodule to ship both 5.3.1 and 6.0.1 and updated the cookbook parameters to use 6.0.1 in Rolling. A build for that is being tested

I was missing the step of re-combining the split files.

[nuclearsandwich]

I was missing the step of re-combining the split files.

This finished but wasn't able to find Connext. @asorbini @clalancette what are your thoughts on setting NDDSHOME or CONNEXTDDS_DIR via the Chef scripts or as part of the ROS 2 batch job? Also @asorbini is there a preferred/recommended variable between the two?

[nuclearsandwich]

Attempt the first to install Connext evaluation binaries. These are no longer tar'd with openssl but it appears to bundle it directly in the .run file. We'll see if there's any additional steps required to get security working.

[asorbini]

Thank you for these updates @nuclearsandwich, a few comments on some of the issues:

I updated the entry_point.sh script to source the rtisetenv script since there's "guessing" logic in rti_connext_dds_cmake_module which is looking for 5.3.1 and does not find 6.0.1.

The "guessing logic" in rti_connext_dds_cmake_module should only focus on coming up with a value for CONNEXTDDS_ARCH, if unspecified. The module calls find_package(RTIConnextDDS ...) with version "5.3.1" but that should only be the "minimum required version". In my experience, I haven't had any problems with finding 6.0.1, since that version number is greater or equal to the specified minimum.

Can you provide some more info on what problems you experienced when trying to load 6.0.1?

rti_connext_dds_cmake_module doesn't really need the rtisetenv script to be sourced, all that is needed is setting CONNEXTDDS_DIR and CONNEXTDDS_ARCH. Since those variables are basically encoded in the rtisetenv script's path, the call to source the script could be replaced with an export, e.g.:

# instead of:
 if test -r /opt/rti.com/rti_connext_dds-6.0.1/resource/scripts/rtisetenv_x64Linux4gcc7.3.0.sh; then
                echo "Sourcing RTI setenv script /opt/rti.com/rti_connext_dds-6.0.1/resource/scripts/rtisetenv_x64Linux4gcc7.3.0.sh"
                . /opt/rti.com/rti_connext_dds-6.0.1/resource/scripts/rtisetenv_x64Linux4gcc7.3.0.sh
elif test -r /opt/rti.com/rti_connext_dds-5.3.1/resource/scripts/rtisetenv_x64Linux3gcc5.4.0.bash; then
                echo "rti_connextdds_cmake_module will guess the location of Connext 5.3.1 so don't source anything."

# we could do:
if test -d /opt/rti.com/rti_connext_dds-6.0.1/lib/x64Linux4gcc7.3.0; then
    export CONNEXTDDS_DIR=/opt/rti.com/rti_connext_dds-6.0.1 \
           CONNEXTDDS_ARCH=x64Linux4gcc7.3.0
if test -d /opt/rti.com/rti_connext_dds-5.3.1/lib/x64Linux3gcc5.4.0; then
    export CONNEXTDDS_DIR=/opt/rti.com/rti_connext_dds-5.3.1 \
           CONNEXTDDS_ARCH=x64Linux3gcc5.4.0

The rtisetenv also sets LD_LIBRARY_PATH, but that's not needed to load the libraries and build rmw_connextdds. At runtime, rti_connext_dds_cmake_module installs a shell hook which will update that variable on its own.

I'm not yet sure whether the .debs are able to be used for DDS security tests. Build Status should give us a hint. If they can, I'd propose that we make that the default and only installation method for 6.0.1 on Linux in order to remove some CI complexity.

As you found out, the .debs do not contain the Security extensions, only the basic libraries.

Based on the test output it looks like the answer is no. That's a bummer. I'll have to look at getting the evaluation binaries installed on Linux as well.

Keep in mind that you have also access to the non-eval bundles (for both 5.3.1 and 6.0.1) which can be installed in "unattended" mode, without requiring a dedicated pexpect python script. I guess they could be provisioned similarly to the approach used for the Windows ones.

This finished but wasn't able to find Connext. @asorbini @clalancette what are your thoughts on setting NDDSHOME or CONNEXTDDS_DIR via the Chef scripts or as part of the ROS 2 batch job?

That would be the preferred way for me. The rti_connext_dds_cmake_module expects either one of those variables to be set by the calling environment and it will not try to guess them, as you found out.

Also @asorbini is there a preferred/recommended variable between the two?

NDDSHOME is the variable that's been used "historically" by Connext ("ndds" in an earlier life), to identify the installation directory. We have gradually introduced CONNEXTDDS_DIR in recent years as an alternative, and I chose to support both in rmw_connextdds/rti_connext_dds_cmake_module, with CONNEXTDDS_DIR taking priority over NDDSHOME, in order to more easily support compilation and usage of rmw_connextdds + Connext 6 alongside rmw_connext_cpp + Connext 5 in the early days of development.

My preference would go to CONNEXTDDS_DIR, since I'm looking forward to a future where NDDSHOME is eventually phased out :)

[nuclearsandwich]

Can you provide some more info on what problems you experienced when trying to load 6.0.1?

I think all my specific issues are discussed upthread. I've been documenting some of the whack-a-mole approach to getting this working through the various places this hooks into our infrastructure but I think with your latest comments I've got paths forward everywhere. I'll keep documenting the whack-a-mole primarily to aid my future self in adding support for additional connext versions going forward and ping you directly if I run into any roadblocks or would like fresh advice. Thanks!

As you found out, the .debs do not contain the Security extensions, only the basic libraries.

I'll send you an email about this as it complicates some future infrastructure changes that we have in the pipeline. Thanks for confirming it.

rti_connext_dds_cmake_module doesn't really need the rtisetenv script to be sourced, all that is needed is setting CONNEXTDDS_DIR and CONNEXTDDS_ARCH. Since those variables are basically encoded in the rtisetenv script's path, the call to source the script could be replaced with an export, e.g.:

The rtisetenv also sets LD_LIBRARY_PATH, but that's not needed to load the libraries and build rmw_connextdds. At runtime, rti_connext_dds_cmake_module installs a shell hook which will update that variable on its own.

This is good info. We have a couple of different build scenarios we need to handle across our infrastructure and documentation:

• User installation from source on Linux
• User installation from source on Windows
• ci.ros2.org on Windows
• ci.ros2.org on Linux (debs or eval bundles)
• CI jobs on build.ros2.org
• Binary packaging jobs on build.ros2.org

Ideally each of these would work the exact same way so that the procedures we document for end-users match what we verify each night in our infrastructure nightlies. The binary packaging jobs for the both the old connext_dds_module and current rti_connext_dds_cmake_module packages include patches to support sourcing a slightly modified for sh compatibility copy of the setenv script in that package.
From their the _cmake_module can include environment hooks to make sure all downstream builds have the needed environment variables set.

Because that's what we're doing for our binary packages I'd like to use the same procedure (sourcing the rti setenv scripts) across all our infra and projects. If there's a preference to change those patches to just set CONNEXTDDS_DIR then I would want to propagate that change throughout our infrastructure and installation instructions.

In a pros/cons discussion. I like the transparency of "just setting an environment variable" versus running an executable script that can perform any number of operations but I like the future-proof nature of running a script provided by RTI to make any adjustments to the environs required so that there's a consistent interface that's somewhat immune to platform-specific changes. When adding the inertia of continuing to do what we're already doing I'd probably lean toward continuing to source the setenv script but I could very easily be swayed by additional arguments to make the switch to the environment variables.

[nuclearsandwich]

My preference would go to CONNEXTDDS_DIR, since I'm looking forward to a future where NDDSHOME is eventually phased out :)

This is exactly what I wanted to know. Thanks!

[nuclearsandwich]

Attempt to use the unattended installer on Linux

[nuclearsandwich]

I've updated the Linux builds to use Connext 6.0.1 pro with security extensions distributed via private submodule.

We'll see how many shell typos I made along the way

[nuclearsandwich]

Well it took a few tries but here we are with Security extensions on Linux

[nuclearsandwich]

Ubuntu Jammy AMD64 Connext Debs full CI
Ubuntu Jammy AMD64 Connext pro bundle full CI
Windows AMD64 Connext pro bundle full CI
Ubuntu Focal AMD64 Connext Debs (5.3.1) up to test_security (installation regression check)
Ubuntu Focal AMD64 Connext eval bundle (5.3.1) up to test_security (installation regression check)

[nuclearsandwich]

Once ros-infrastructure/ros2-cookbooks#40 is reviewed for Windows we can update this PR to point back to latest in the Windows chef cookbook.

[clalancette]

Everything I left here is a nit. I'll leave it up to you whether it is worth addressing all, none, or some of the things I pointed out.

[clalancette]

That's fine, this isn't a blocking problem anyway. Just curious about it.

[nuclearsandwich]

Ubuntu Focal AMD64 Connext Debs (5.3.1) up to test_security (installation regression check)

✅ Connext 5.3.1 is installed via debs and rti_connext_dds_cmake_module finds it.
✅ Security tests do not pass due to lack of security extensions.

Ubuntu Focal AMD64 Connext eval bundle (5.3.1) up to test_security (installation regression check)

✅ Connext 5.3.1 is installed via pexpect script and rti_connext_dds_module finds it.
✅ test_security tests pass
✅ this error seems present in both 5.3.1 and 6.0.1 when Connext is the only/default rmw_implementation

[nuclearsandwich]

Ubuntu Jammy AMD64 Connext pro bundle full CI

✅ Connext 6.0.1 is installed via pro bundle with pexpect script (we could use the unattended mode but the pexpect script is working and I'd rather wait to refactor until we don't need it for 5.3.1)
✅ test_security tests pass
✅ this error seems presen in both 5.3.1 and 6.0.1 when Connext is the only/default rmw implementation.

[nuclearsandwich]

Ubuntu Jammy AMD64 Connext Debs full CI

✅ mypy tests are expected on Jammy right now (see #617)
✅ this error seems present in both 5.3.1 and 6.0.1 when Connext is the only/default rmw implementation.
✅ security tests fail because the deb lacks support for RTI security extensions.

[nuclearsandwich]

Based on the test results for the last Windows job it does not appear that rmw_connextdds was used to run security tests.

[nuclearsandwich]

Based on the test results for the last Windows job it does not appear that rmw_connextdds was used to run security tests.

This is also true in the nightlies. The tests are only run for rmw_cyclonedds and rmw_fastrtps https://ci.ros2.org/view/nightly/job/nightly_win_rel/2205/testReport/test_security/TestSecurePublisherSubscriber/

[nuclearsandwich]

Windows AMD64 Connext pro bundle full CI

✅ ConnextDDS 6.0.1 is properly installed and detected.
✅ rclpy and other test failures are present in nightlies on Windows
✅ security tests are not run in a full CI build with rmw_connextdds

[nuclearsandwich]

One last test to verify that 5.3.1 still installs successfully for a non-Rolling configuration.

Windows AMD64 Galactic pro bundle