Multiple environments (RouDis)

[niclar]

Hi what's the recommended path of running two separate iceoryx environments on the same box if possible ?

I rather not send under separate topics and share RouDi. I see that Roudi can start with an unique Id but the PoshRuntime can't register per runtime Id... -I suspect I'm missing something.

Please advice. Thanks!

Edited from elBoberido on Feb 13th 2024

Tasks

• [x] using unique RouDi ID as prefix in the resource names -> #2185
• [x] non-static posh runtime/node
• [x] builder pattern for the posh runtime/node to easily create multiple runtimes for various RouDi
• [x] gracefully handle the non-existence of a RouDi; operation can continue in a degraded fashion only with the available RouDi
• [ ] builder pattern for the endpoints to determine which runtime to use and handle errors more gracefully
  • the runtime itself could act as factory for the endpoint builders
• [x] standardized environment variable to define the domain ID for the applications -> IOX_DOMAIN_ID
• [ ] the domain ID must be added to the segment_id_t in order to have multiple active runtimes in the same process
  • each runtime needs to register to a different RouDi
  • if there are two runtimes trying to register at the same RouDi, the pointer repository registration will fail
    • this could be solved via ref-counting on the register/unregister calls
• [ ] port all code to the new builder pattern API
• [ ] deprecate the old API

Since this is a larger feature and most probably won't be finished at once, the changes will either live on a separate feature branch or if possible behind a feature flag, e.g. IOX_EXPERIMENTAL_POSH

[elfenpiff]

@niclar This is a feature we have in mind and is on our todo list but sadly not in the next weeks. @budrus can you shine some light on it when we could start working on this?

But if you want to separate the RouDi instance for security/safety reasons we already have a feature in place which separates the process in a way that they cannot read/write data/memory which they aren't supposed to. For this you configure multiple shared memory segments and let the processes run under different groups, see: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/advanced/configuration-guide.md for the documentation and https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/ice_access_control for the code example.

This feature is not yet finalized but you could use this as a starting point and when we finalize the feature you do not have to change much in the code (or in the best case nothing). The missing piece is that all application at the moment require read/write access to the shared memory management segment of roudi - this should not be necessary.

[budrus]

As @elfenpiff wrote, we currently do not support this. The unique ID for RouDi is a first step and supporting this is definitely on the wish list for a 2.1 or 3.0 release. What exactly is your use case @niclar?

[niclar]

@burus I want to run two separate systems / stacks (production-staging, production) on the same machine (different prio, communicating modules, config, etc.). Until this feature is in place I'll "just" publish under different topics (instanceIds) and share RouDi.

[elBoberido]

@niclar would it be an option to run the production-staging RouDi in a docker environment?

[niclar]

We don't run docker and that would introduce discrepancies in A/B testing wrt networking, latencies etc.