This means that if ROS_LOCALHOST_ONLY is not set, it is just up to rmw implementation? that means, changing rmw implementation via environmental variable changes application behavior pretty much? i think it would be nice to define the default in ROS 2?

The behavior in rcl is to use RMW_AUTOMATIC_DISCOVERY_RANGE_LOCALHOST if no value is given for the environment variable.

I think it's worth considering removing the RMW_AUTOMATIC_DISCOVERY_RANGE_DEFAULT value entirely since it currently will never get passed to rmw from rcl, and furthermore we're expecting the RMW implementations to implement ..._DEFAULT the same as ..._LOCALHOST anyway. Having this redundancy is probably just creating confusion and not accomplishing anything.

The QoS enums have a *_SYSTEM_DEFAULT value. I forget what this was for. Was it to allow setting QoS via a middleware specific configuration?

If so, RMW_AUTOMATIC_DISCOVERY_RANGE_SYSTEM_DEFAULT might be useful to say "don't mess with discovery settings, they're already configured with middleware specific APIs".

That's right @sloretz.

I think @mxgrey is also right, it's weird if we're never sending the value down to rmw, so we should either not have it as an rmw option or we should handle it in the rmw layer. It might make sense to have ROS/RCL version that has system default but not have one in RMW if that one doesn't make sense. I know we only have RMW enums atm, however.

However, it might just be that we shouldn't be automatically be converting the DEFAULT into LOCALHOST as we are now.

However, it might just be that we shouldn't be automatically be converting the DEFAULT into LOCALHOST as we are now.

If we are just converting DEFAULT to LOCALHOST ( I see that happening in the rmw_cyclonedds_cpp PR) then I agree it doesn't seem like an option at the RMW layer is necessary.

If someone wants to use an XML config, and doesn't want the rmw_* layer to mess with discovery settings, and the default discovery range is localhost, what option should they provide for the range? SUBNET since the default behavior seems to be to do nothing, at least for cyclonedds?

What if system has multiple network interface? that is also rmw implementation dependent as it is now?

Yes. That is out of scope of this PR.

What about the one is with hostname which can be DNSed to IP, and the other with the same IP address? that is not supported here?

The main use case for this is testing and configuration. So yes, this means that discovery_params which has a hostname that can be DNSed to some other host name is considered a different configuration.