Add ros2 nightly variant with added RMW vendors

[ruffsl]

This allow the installation of all supported RMW layers for testing.
Total image therefore size increases: 3.56GB -> 4.31GB
However, the nightl tag is not meant to be used for deployments, but rather CI testing.

Relates to: osrf/docker_templates#68

[mikaelarguedas]

LGTM,

WIth one comment about installing colcon from pip vs apt.

We may need to add it to the cron job triggering the nightly build of the nightly image (@nuclearsandwich )

[mikaelarguedas]

lgtm 👍

[nuclearsandwich]

We may need to add it to the cron job triggering the nightly build of the nightly image (@nuclearsandwich )

That shouldn't be a problem. Once we're ready to start building the new image send me a ping and I'll add the entry.

[nuclearsandwich]

I am not sure about accepting the Connext license and the distributing the image without announcing the license agreement. A consumer of the nightly-rmw image will have no indication that by using the image they're agreeing to a license.

If we install RTI Connext as part of our build process in order to provide possible support, I think we should remove it (and the license agreement environment variable) and potentially provide some entrypoint magic or other logic to allow users of the resulting image to opt explicitly into installing Connext for use.

[ruffsl]

I am not sure about accepting the Connext license and the distributing the image without announcing the license agreement. A consumer of the nightly-rmw image will have no indication that by using the image they're agreeing to a license.

How about we extend a related PR #285 to include more descriptions of tags and target use case, as well as the notice of third party license agreements that are included in the nightly-rmw tag:

---

• nightly
  • Description: includes pre-installed builds from nightly job on the build farm, prepared so the environment closely resembles that of official library repo.
  • Purpose: this tag is intended for CI and testing against the latest nightly builds to help early detection of regressions or deprications from upstream.
• nightly-rmw
  • Description: building FROM the nightly, this tag also includes all available RMW implementations and respective vendor libraries.
  • Purpose: this tag is intended for CI and testing against all possible RMW vendors to help early detection of regressions or deprications from upstream.
  • Notice: this tag includes third party license agreements from specific RMW implementations, specifically the Open Community Source license from RTI for Connext DDS.

[mikaelarguedas]

I am not sure about accepting the Connext license and the distributing the image without announcing the license agreement. A consumer of the nightly-rmw image will have no indication that by using the image they're agreeing to a license.

Thanks @nuclearsandwich for binging it up. We initially discussed it offline and forgot to get back to it when the PR was opened.

Do you thing mentionning it in the description is enough? Or reflecting it in the tag name would be preferred, e.g. something like osrf:nightly-rmw-nonfree ?

[ruffsl]

Or reflecting it in the tag name would be preferred, e.g. something like osrf:nightly-rmw-nonfree ?

That seems rather clear, similar to how ubuntu handled such things in linux:
https://launchpad.net/ubuntu/+source/linux-firmware-nonfree

[nuclearsandwich]

Do you thing mentionning it in the description is enough? Or reflecting it in the tag name would be preferred, e.g. something like osrf:nightly-rmw-nonfree?

To be honest, I don't know, I think we would need to ask RTI. Personally I have a strong preference that users take explicit action to agree to any non-OSI license.

[ruffsl]

I think we would need to ask RTI.

I've emailed RTI about this, pointing to this discussion and CC'ing you all as well.

[ruffsl]

I've emailed RTI about this, pointing to this discussion and CC'ing you all as well.

We've received written confirmation today from Gerardo via Nicole that is use is perishable with RTI.
I'll go ahead and open a separate PR to include the added notice and descriptions for repos/tags.

[ruffsl]

Do you think we should split this into three tags that would have the follow pattern:

• osrf/ros2:nightly
  • include default rmw (Fast-RTPS)
• osrf/ros2:nightly-rmw
  • FROM osrf/ros2:nightly
  • include non default rmw (OpenDDS, Opensplice, Vortex, Cyclone, etc..)
• ros2:nightly-rmw-nonfree
  • FROM osrf/ros2:nightly-rmw
  • include non free rmw (Connext, etc..)

---

@mikaelarguedas , when you manually retriggered osrf/ros2:nightly, did you manually retrigger nightly-rmw in the UI as well, or did the REPOSITORY LINKS option in the automated build setting actually work for nested tags now! Looking the build timeline, it seems like it is building devel, nightly, and my the test rmw tags in lockstep. Unless @nuclearsandwich has already included the trigger webhook for the rmw tag on the con job.

I'm thinking we could also move that cron job to travis so we can all see what's configured and when it runs or fails to run.

[mikaelarguedas]

Do you think we should split this into three tags that would have the follow pattern:
Makes sense to me. If not the third tag, I feel like the one containing proprietary code should state it in the name with a nonfree suffix.

I guess there is a case to be made regarding not providing it at all. We could provide a osrf/ros2:nightly-rmw with all Open source implementations. And link users to pages on how to install the proprietary packages on top.

---

• osrf/ros2:nightly-rmw
• FROM osrf/ros2:nightly
  include non default rmw (OpenDDS, Opensplice, Vortex, Cyclone, etc..)
• ros2:nightly-rmw-nonfree
  • FROM osrf/ros2:nightly-rmw
    include non free rmw (Connext, etc..)

We should explicitly state in the docs what implementations the images are built against. Users wanting to test other implementations need not only to have another implementation installed but to rebuild the stack.

---

did you manually retrigger nightly-rmw in the UI as well, or did the REPOSITORY LINKS option in the automated build setting actually work for nested tags now!

Triggered it by hand, sorry for the false hope

I'm thinking we could also move that cron job to travis so we can all see what's configured and when it runs or fails to run.

IIRC the goal was to integrate that into ci.ros2.org to be triggered after nightly packaging job succeeds.
But putting it in travis is fine by me too.

[ruffsl]

And link users to pages on how to install the proprietary packages on top.

I think that would lead to fractured development; the fragility with everyone having to reimplement their own strategy or shim-image that would then install the desired vendor on top of the nightly image, that their CI images would then dog food FROM. Thats a lot of leg work for each user to have to repeat; as I've have to do that a number of times. I think if we keep it standardized here it would be a lot easier for users to integrate with.

We should explicitly state in the docs what implementations the images are built against. Users wanting to test other implementations need not only to have another implementation installed but to rebuild the stack.

I'm already working this into a new PR: #295 (comment)

Triggered it by hand, sorry for the false hope

But not all the previous ones then, no?
I think They might be triggering by tag now!

IIRC the goal was to integrate that into ci.ros2.org to be triggered after nightly packaging job succeeds.
But putting it in travis is fine by me too.

Could we still have a badge that links to its status on jenkins?
I'd like like the README to warn me if something's up at a glance.

[ruffsl]

Ok, now that the new docs are ready, and we've received approval from RTI,
I'm going to merge these PRs for added nightly tags and test them some more with nav2 CI pipeline.
Users who do not want to test with non free software may still opt for ros2:nightly-rmw.