Add per node & component log level support

[penww]

Description

This issue tracks the addition of a log_level field to NodeOptions, allowing users to set the initial log severity for a node at construction time. This enables per-component log level customization, particularly useful in component container deployments.

Motivation

In ROS 2, all nodes loaded into a component container share the same process. Prior to this change, there was no way to specify a different initial log level for individual components at load time — the only option was to set a global log level or call set_level() programmatically after construction.

This is a common need in production deployments where:

• Different components have different verbosity requirements (e.g., a sensor driver at WARN, a planner at DEBUG).
• Operators want to configure log levels declaratively via launch files or LoadNode service calls without modifying node source code.
• Debugging a single component in a multi-component container should not require restarting the entire process with a global log level change.

We can see this feature has designed but not full implementation:

• LoadNode.srv defined log_level field: https://github.com/ros2/rcl_interfaces/blob/79a773f9fb02dee0de23fb1b08ca4d187b313849/composition_interfaces/srv/LoadNode.srv#L17
• ros2component implement log_level args but not parse: https://github.com/ros2/ros2cli/blob/401876461924b6bd4d4f9db95e22deb6243fce8b/ros2component/ros2component/api/__init__.py#L343
• component_manager not handle log_level in the LoadNode request:

  rclcpp/rclcpp_components/src/component_manager.cpp

  Line 150 in f145c9e

  ComponentManager::create_node_options(const std::shared_ptr<LoadNode::Request> request)

Expected Behavior:

• Set component log_level with CLI:

ros2 component load /ComponentManager <PKG> <PLUGIN> --log-level debug

• Set component log_level with launch:

def generate_launch_description():
    return LaunchDescription([ComposableNodeContainer(
        name='component_demo_container',
        namespace='',
        package='rclcpp_components',
        executable='component_container',
        composable_node_descriptions=[
            ComposableNode(
                package='<PKG>',
                plugin='<PLUGIN>',
                log_level='DEBUG',  # component log level
            ),
        ],
        arguments=['--ros-args', '--log-level', 'DEBUG'],  # container log level
    )])

Design / Implementation Considerations

NodeOptions API

A new log_level getter/setter pair is added to NodeOptions:

// Get the log level (RCUTILS_LOG_SEVERITY_* value; 0 = unset/default)
int log_level() const;

// Set the initial log level for this node
NodeOptions & log_level(int log_level);

The default value is RCUTILS_LOG_SEVERITY_UNSET (0), which preserves existing behavior — no level is applied at construction.

Node construction (node.cpp)

After the node is fully constructed, if log_level is not UNSET, the logger level is applied:

if (options.log_level() != RCUTILS_LOG_SEVERITY_UNSET) {
  node_logging_->get_logger().set_level(
    static_cast<rclcpp::Logger::Level>(options.log_level()));
}

This is intentionally applied after construction so the logger is fully initialized.

ComponentManager integration (component_manager.cpp)

When handling a LoadNode service request, the log_level field from the request is validated and forwarded to NodeOptions:

if (request->log_level != 0) {
  // Validate against known RCUTILS severity values
  options.log_level(request->log_level);
}

Invalid values (not one of DEBUG, INFO, WARN, ERROR, FATAL) throw a ComponentManagerException with a descriptive message.

Additional Information

No response

[vishwakarmanilesh7398-driod]

Hello @penww, this is a much-needed feature for component-based deployments. I've been following the PRs (#3092 and ros2cli#1212). I am interested in helping with the testing of this feature on Ubuntu 24.04 (Jazzy) and verifying if the error handling for invalid log levels is robust. Is there any specific area where you need more hands or additional test cases?

[mjcarroll]

@penww thanks for opening some pull requests here, I will assign this issue to you.

@vishwakarmanilesh7398-driod would appreciate any reviews/testing you can give to the pull requests now that they are up.

[vishwakarmanilesh7398-driod]

"Thanks @mjcarroll for the opportunity to review this.

I've analyzed the CI failure in subscription_base.cpp and it seems unrelated to the log_level changes in this PR—likely a sync issue with the underlying rcl layers.

Regarding the code in #3092:

I noticed that @penww used rclcpp::Logger::Level instead of a raw int. This is a great choice for type safety, and using Unset as default is perfect for backward compatibility.

I'm currently verifying how the ComponentManager handles the transition from CLI strings (like 'debug') to this enum.

I'll share my full testing results on Ubuntu 24.04 (Jazzy) once I've finished the manual build."

[penww]

@vishwakarmanilesh7398-driod Thanks for helping test this change. For CI failure, @InvincibleRMC have triggered external rosci for verification. I will track the PRs to merge them ASAP.

BTW, I will submit another PR to launch_ros to add support for configuring log_level in launch scripts.

[vishwakarmanilesh7398-driod]

"I have thoroughly reviewed the code changes in node_options.hpp, node_options.cpp, and the validation logic in component_manager.cpp (Line 180-193). The implementation correctly handles log level settings and throws a ComponentManagerException for invalid values, ensuring robustness. Since I am on a Windows environment and currently setting up the rolling base, I have verified the logic statically and it LGTM (Looks Good To Me)."

[jmachowinski]

PR has been merged, closing the ticket as solved.

[fujitatomoya]

@jmachowinski why did you close this issue? ros2/launch_ros#531 has not been merge yet???

[penww]

Hi @fujitatomoya, thanks for your feedback, maybe @jmachowinski means we should open issue at ros2/launch_ros repo.