Future of migration from gazebo to Ignition

[ruffsl]

What should we be doing for the future with Ignition? Should we migrate to new docker hub repo, or just merge the tags back into gazebo repo, sort of like what we did with ROS2 and the ros docker hub library repo? I'd be in favor of retiring the gazebo repo, and opening a new repo for ignition, given the namespace still seems available: https://hub.docker.com/_/ignition

[mikaelarguedas]

I'd be in favor of retiring the gazebo repo

If we decide to move forward with https://github.com/osrf/docker_images/issues/353 I'd be in favor of NOT retiring the repo. Especially with the release of Gazebo 11 coming out.

opening a new repo for ignition

I can go either way, if the repo is available might as well just move to a dedicated repository.

[ruffsl]

Especially with the release of Gazebo 11 coming out.

Well, guess I meant until the final release is made, and by retiring I mean not reusing it for ignition tags.

I can go either way, if the repo is available might as well just move to a dedicated repository.

Does the Gazebo/Ignition team have an idea on how they want to brand things. Are the ignition libraries only really used for Gazebo, or is Gazebo now only a small part of Ignition? @scpeters @chapulina

[chapulina]

runtil the final release is made

Gazebo 11 will be released this month and will be supported until 2025, so we have some time until it can be retired :wink:

how they want to brand things

We're a bit all over the place right now. If ignition / ignitionrobotics are available, I'd suggest we move there to keep things a bit more organized.

[mikaelarguedas]

If ignition / ignitionrobotics are available, I'd suggest we move there to keep things a bit more organized.

Both names seem available. Is there a preference ?

[mikaelarguedas]

Well, guess I meant until the final release is made, and by retiring I mean not reusing it for ignition tags.

Actually in light of https://github.com/osrf/docker_images/issues/353#issuecomment-575880060 I'm now in favor of retiring it as it doesn't hold any image and likely won't hold any for gazebo11 either ;).

[ruffsl]

Both names seem available. Is there a preference ?

I'd recommend just ignition, as its simply shorter to type everyday and is still available, plus that the metapackages and libraries are all prefixed with ignition, e.g. ignition-acropolis or ign-*:

https://ignitionrobotics.org/docs/acropolis/install#option-1-installation-on-ubuntu-bionic

Even the web page/tab name of the docs is "Ignition - Docs: Install"

[mikaelarguedas]

I'd recommend just ignition

Yeah that's my feeling as well :+1: That seems to also be the language used to refer to the releases and for the artwork. As the other name was brought up I figured there was maybe a preference for it (match the website name, bitbucket org name etc)

[chapulina]

ignition is fine :+1: Thanks for taking care of this, peeps!

[mikaelarguedas]

@chapulina Is there a plan of making a packaging layout allowing to install the GUI stuff separately ? (like one package for the server, another one for the client etc) Or it will be like gazebo and we should make a single image installing ignition-<release-name> ?

[chapulina]

I don't think there are any plans right now, but I can't see why not do that with the goal of reducing server-only images.

@j-rivero , what do you think of splitting the Ignition Gazebo package starting with Dome? Not only GUI could be optional, but also rendering. We could even create a separate package for each plugin like we're doing for Ignition Sensors.

[ruffsl]

Not only GUI could be optional, but also rendering.

Does Ignition still need a x11 virtual frame buffer for rendering sensor images for headless simulations?

[chapulina]

Does Ignition still need a x11 virtual frame buffer for rendering sensor images for headless simulations?

Yes, that part works like Gazebo-classic.

[mjcarroll]

There is a slight chance of EGL support in the future, but that's going to depend on OGRE's support for it, and it's not on our roadmap yet.

For now, you'll have to assume the framebuffer is necessary.

On Wed, Jan 22, 2020, 17:04 chapulina notifications@github.com wrote:

Does Ignition still need a x11 virtual frame buffer for rendering sensor images for headless simulations?

Yes, that part works like Gazebo-classic.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/osrf/docker_images/issues/354?email_source=notifications&email_token=AACEJFOFISOAQRIRRAZYVM3Q7DGH5A5CNFSM4KIPDQE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJVNS6A#issuecomment-577427832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACEJFPVZILFBFCBWUVNHLLQ7DGH5ANCNFSM4KIPDQEQ .

[ruffsl]

@chapulina @mjcarroll any updates? Should we try again to push this over the finish line? Are there a common set tags we should start with?

[mjcarroll]

At least on the framebuffer bit, we now have support for EGL and doing OpenGL without the need of a framebuffer. Our builds are still pretty tied together in terms of the gui and non-gui portions, we haven't made any headway on that.

I think if we want to use source builds, then using gazebodistro (https://github.com/ignition-tooling/gazebodistro/blob/master/collection-fortress.yaml) makes the most sense per collection.

The alternative is to use the debs from our package mirror and apt install ignition-<collection>.

Should I get someone inside our org to reserve the name and get permissions set up for you?

[ruffsl]

then using gazebodistro

Is there any segmental hierarchy there? E.g. like the meta package/tags we use for the ros images. Or should we just bundle a ignition server install and call it a day? I'm not sure how useful the deafferentation between the libgazebo vs gzserver tags really were.

Should I get someone inside our org to reserve the name and get permissions set up for you?

Once we have ignition Dockerfiles and manifest in this repo ready, then any one of us could open up a upstream PR to the official docker library repo like before.

[chapulina]

Hi @ruffsl , thanks for getting back to this!

Should we migrate to new docker hub repo, or just merge the tags back into gazebo repo

Can we do the same that we've been doing for Gazebo classic? That's already setup and should provide a smoother transition and easier discoverability. I believe that would be a combination of https://hub.docker.com/_/gazebo and https://hub.docker.com/r/osrf/gazebo/. Not sure exactly what should go into each now that Gazebo has EGL support and doesn't require NVIDIA docker anymore.

Or should we just bundle a ignition server install and call it a day?

Yeah that sounds like the most common use case, so I don't think we need to worry about splitting it further.

[mikaelarguedas]

Hi there!

I suppose with the re-rename of gazebo the strategy here can change.

How would we go to add new Gazebo distros to the existing gazebo images on dockerhub ?

[ruffsl]

Looks like the stall in taking action for this ticket has (perhaps fortunately) outlived the issue in re-naming the image repo.

How would we go to add new Gazebo distros to the existing gazebo images on dockerhub ?

With the EOL of gazebo classic, perhaps we could archive all of the existing version numbered subdirectories into a subdirectory called classic in the root gazebo folder, in order to make room for the next/newer gazebo distro named folders and scripts.

With respect to the scripts, one annoying thing would be in parameterizing the templates to either use the package naming of ignition or gazebo.

Some open questions, would we like to push tags for older distros of gazebo (when it was called ignition)? I think it might be nice to, for the sake of completeness. We could deprecate them just as soon as they are pushed upstream to the official library. Perhaps just manually modify the Dockerfiles from the gazebo template going forward in order to spare us the complexity for automating EOL gazebo distros.

[moriarty]

:zombie: :thinking: I was surprised today when I wanted to prototype something with the latest version of Gazebo and there isn't an official image... It's not hard to make a local custom image just for quick prototyping it is nice to have especially with the final Gazebo Classic EOL soon approaching

[j-rivero]

I was surprised today when I wanted to prototype something with the latest version of Gazebo and there isn't an official image

Yep, something that has been on my list of things to get back for long but did not find the time for it. However we might be good on time to get this back since there is a GSoC project running where I mentoring Saurabh to improve the Gazebo installations. It is in our list trying to resurrect this official images (if possible).

@mikaelarguedas, @ruffsl what would you suggest as the first steps to include the new Gazebo in the images again?

[ruffsl]

what would you suggest as the first steps to include the new Gazebo in the images again?

Before we start revamping the Dockerfile templates, perhaps it's worth discussing what kind of tag variants gazebo would like to provide?

Similar to the mapping of tags to meta package variants for the ROS docker images, would there be a similar categorization for gazebo?

By the way, did the current version of gazebo ever succeed in partitioning its graphical user interface requirements into separate meta packages, in order to be more amenable for headless simulation with leaner image sizes? For example, the requirements for x11, Mesa utils, and Qt added quite a bit for minimal simulation containers.

[mikaelarguedas]

Indeed,

Are we confident the naming (of packages and commands) will be stable for the future versions or is it still settling ?

I believe multiple questions from here and https://github.com/osrf/docker_images/pull/378 are still open.

The best to move forward would be (as Ruffin suggested):

• what tags are needed
• what high level packages should be install in each of these tags
• how to do server / headless install without bundling GUI dependencies
• define what environment var and commands are expected to be ran in each of these