WIP add Ignition

[mikaelarguedas]

This PR along with osrf/docker_templates#84 provide boilerplate to generate ignition docker files and dockerfiles for Ignition blueprint and citadel.
To be done before merging:

• addressing al open questions below
• opening PRs for repository and doc creation on dockerhub
• removing debug commits like 8f11889

Open questions / remarks (ping @j-rivero @chapulina @ruffsl) :

• This PR includes an image for Blueprint: should we keep it or just provide images for the newer and LTS Citadel?
• Currently the container starts with ign gazebo -s:
  • this is headless so makes sense for an official image
  • doesnt run any actual simulation: ignition doesnt start with a default world (?)
  • do we want to launch an empty world instead ?
• hardcoded gazebo in the package URL http://packages.osrfoundation.org/gazebo/$ID-stable, will this be changed/mirrored to ignition or should we hard code it in the templates ?
• dependencies:
  • ignition-citadeland more precisely libignition-launch2-dev depends on both ignition-gazebo2 and libignition-gazebo3-dev ?! Is it normal to depend on 2 different versions of Gazebo?
  • ignition-citadel depends on libboost-all-dev and a ton of libignition-*-dev packages. Is there another package I should install to have only the runtime libraries in the docker image? (The current ignition-citadel image is 1.46GB which is huge)

[chapulina]

This PR includes an image for Blueprint: should we keep it or just provide images for the newer and LTS Citadel?

Blueprint has 7 more months of support and is the version being used by the current phase of the Subterranean challenge, so I suggest keeping it.

doesnt run any actual simulation: ignition doesnt start with a default world

It does run simulation, but the default world is more conservative than Gazebo's and doesn't even include a sun and ground plane. This might change though.

do we want to launch an empty world instead ?

You could start with empty.sdf, which has the ground plane and sun. My recommendation would be not to make this decision at the docker image though, and just launch Ignition's default.

will this be changed/mirrored to ignition

No plans to change that

libignition-launch2-dev depends on both ignition-gazebo2 and libignition-gazebo3-dev

Oops, fix here: gazebo-release/gz-launch2-release#1

Is it normal to depend on 2 different versions of Gazebo?

Nope, but hey, they've been working happily side-by-side 😁

Is there another package I should install to have only the runtime libraries in the docker image?

I suspect there isn't a way yet. CC @j-rivero

[mikaelarguedas]

Thanks @chapulina for the timely and thorough answer!

Nope, but hey, they've been working happily side-by-side 😁

Yeah amazing 🎉 though confusing ^^

Changes performed, new review requested

[ruffsl]

The current ignition-citadel image is 1.46GB which is huge)

Do we want to use the same --no-suggested-depends like in other library PRs?

[mikaelarguedas]

Do we want to use the same --no-suggested-depends like in other library PRs?

My original thinking was to keep those dissociated as I don't know when the other PR will land and decision in the other PR may impact the use of --no-install-recommends here as well.
But I can also just roll this into this PR directly if you prefer

@ruffsl some extra questions for the ignition images

• Should we host all of them on the osrf profile as currently there's no way to get a version without gui dependencies
• Should we provide several layers (like in gazebo for gzserver and gzclient) even if at the moment they install the same package? e.g.:
  • server layer: runs ignition gazebo headless: ign gazebo -s
  • client layer: runs ignition gazebo with client and gui: ign gazebo

[ruffsl]

My original thinking was to keep those dissociated as I don't know when the other PR will land and decision in the other PR may impact the use of --no-install-recommends here as well.

That sounds fine, we'll wait for the other PRs to stabilize.

Should we host all of them on the osrf profile as currently there's no way to get a version without gui dependencies

I'd shoot for introducing the server tags we'd like to support, and push them upstream. I think even the current gazebo library tags have gui packages, so I'm not sure that made a difference. I just think moving the tag to a new repo later might be disruptive. Although the other thing we could do is to only support a tag for gui/client install/ then add a headless server related tag when ignition comes up with one, and rebase the osrf gui tag to build from the library tag we'd upstream.

client layer: runs ignition gazebo with client and gui: ign gazebo

I'm not sure you'd ever want to have the GUI to launch as the default command entry point, as unless someone is going spawn the container using rocker, it'd just crash. I think the client related tag should just keep the default cmd that it would inherit from the server tag.

[mikaelarguedas]

Although the other thing we could do is to only support a tag for gui/client install/ then add a headless server related tag when ignition comes up with one, and rebase the osrf gui tag to build from the library tag we'd upstream.

Yeah maybe that makes more sense. Once ignition provide more granular packages and ways to install client and server separately we can consider pushing them to the official library

I'm not sure you'd ever want to have the GUI to launch as the default command entry point, as unless someone is going spawn the container using rocker, it'd just crash. I think the client related tag should just keep the default cmd that it would inherit from the server tag.

Arguably maybe it should do nothing ? like the ROS images where you enter a container with an environment seupt but nothing running. similarly we dont launch a rosmaster in the ROS 1 images.

[ruffsl]

Arguably maybe it should do nothing ? like the ROS images where you enter a container with an environment seupt but nothing running. similarly we dont launch a rosmaster in the ROS 1 images.

Good point. There was a good cause to do this with gazebo, as running gazebo was perhaps the main purpose of the gazebo images, but now with gazebo being only a part of the ignition ecosystem, perhaps it makes sense to follow the approach in the ros images.

[chapulina]

Hi peeps, what's the status on this? Anything we can help with?

[mikaelarguedas]

what's the status on this?

no updates on this ATM mostly because time is lacking

Anything we can help with?

Is there now a way to install only the server side of things without bundling in all the GUI dependencies ? this would go a long way in providing images following the docker guidelines

There doesn't seem to be arm packages for ignition-citadel or ignition-dome. Is arm64 not a supported platform ?

[chapulina]

Is there now a way to install only the server side of things without bundling in all the GUI dependencies ?

Nope. I ticketed gazebosim/gz-sim#398 to keep track of this.

Is arm64 not a supported platform ?

Dome is already there on Focal, and almost there on Bionic. That's being tracked on gazebo-tooling/release-tools#297 but it's low priority for us at the moment.

We don't have an issue tracking Citadel yet.

[mikaelarguedas]

I started revisiting this in light of ignition name change.

AFAICT:

• it may make sense to host future gazebo images under osrf/gazebo like the current ones

• A specific template would be needed for ignition - gazebo packages but it may not be that case starting with Garden (to confirm)

• There is ATM no packages providing non-GUI components of gazebo so the images will not be hosted in the official docker library

• There will not be officially supported ARM packages for the near future

• The containers default command will be "ign gazebo -s" to run headless. This command is subject to change , what would it become?

  • gz gazebo -s
  • gazebo -s
  • something else ?

• The set of image would have the following naming:

  • osrf/gazebo:citadel-bionic
  • osrf/gazebo:citadel-focal
  • osrf/gazebo:fortress-focal
  • osrf/gazebo:fortress-jammy

@chapulina Could you provide feedback on the former points ?

---

Side troubleshooting question: Locally the citadel images seem to do what's expected, however the fortress ones crash with the following message:
[Err] [Server.cc:109] Failed to find world []
Is it necessary to pass extra argument in Fortress for the simulator to start with a default / empty world ?

[chapulina]

it may make sense to host future gazebo images under osrf/gazebo like the current ones

👍🏽

A specific template would be needed for ignition - gazebo packages but it may not be that case starting with Garden (to confirm)

I haven't looked into these templates. What parameters are passed to a template?

There is ATM no packages providing non-GUI components of gazebo so the images will not be hosted in the official docker library

I don't know what the rules are for hosting under the official docker library. Is it ok to install GUI dependencies, but not require them for running? From Fortress we support headless rendering, so you could run with -s for no GUI and --headless-rendering to use EGL in a container.

There will not be officially supported ARM packages for the near future

We have some, but they're supported at best effort and may be broken for extended periods of time.

The containers default command will be "ign gazebo -s" to run headless. This command is subject to change , what would it become?

gz sim -s

The set of image would have the following naming:

👍🏽

Locally the citadel images seem to do what's expected, however the fortress ones crash with the following message:

We need a release with gazebosim/gz-sim#1463, I can make it soon. And to confirm, does it actually crash or does it shutdown gracefully?