-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add verbose in service-info verb #916
base: rolling
Are you sure you want to change the base?
Conversation
Signed-off-by: Minju, Lee <[email protected]>
@leeminju531 thanks for taking care of this! i will try to review all incoming PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall lgtm
@@ -231,6 +244,40 @@ def test_get_subscriptions_info_by_topic(daemon_node): | |||
TEST_TOPIC_SUBSCRIPTION_QOS.reliability | |||
|
|||
|
|||
def test_get_clients_info_by_service(daemon_node): | |||
clients_info = daemon_node.get_clients_info_by_service(TEST_SERVICE_NAME) | |||
assert len(clients_info) >= 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be one that is only matching with the service? if that is correct, probably we do not need the following for
statement either.
assert len(clients_info) >= 1 | |
assert len(clients_info) == 1 |
|
||
def test_get_servers_info_by_service(daemon_node): | ||
servers_info = daemon_node.get_servers_info_by_service(TEST_SERVICE_NAME) | ||
assert len(servers_info) >= 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, should it be one?
assert len(servers_info) >= 1 | |
assert len(servers_info) == 1 |
I think that we need to have discussion on the behavior of this verbose option. instead, i would suggest that it displays as service endpoint for client and server endpoint. i am now inclined to support this feature as service endpoint but exposing hidden topics. (rmw implementation needs to be aware of hidden topics but rcl or upper layer do not need to know that hidden topics at all.) |
Sorry for coming back too late. Displaying the However, I wonder if we could define and populate a The /// A data structure that encapsulates the node name, node namespace,
/// topic_type, gid, and qos_profile of publishers and subscriptions
/// for a topic.
typedef struct RMW_PUBLIC_TYPE rmw_topic_endpoint_info_s
{
/// Name of the node
const char * node_name;
/// Namespace of the node
const char * node_namespace;
/// The associated topic type's name
const char * topic_type;
/// Hashed value for topic type's description
rosidl_type_hash_t topic_type_hash;
/// The endpoint type
rmw_endpoint_type_t endpoint_type;
/// The GID of the endpoint
uint8_t endpoint_gid[RMW_GID_STORAGE_SIZE];
/// QoS profile of the endpoint
rmw_qos_profile_t qos_profile;
} rmw_topic_endpoint_info_t; To represent the
Does that make sense? |
@leeminju531 or how about landing in the middle? that means include the topic type, topic hash and GID under the
if rmw implementation does not construct the service based on topics, these |
Verbose option in service info verb
Expected
Dependencies
rmw
rmw_implementation
rmw_fastrtps
rmw_cyclonedds
rmw_connextdds
rcl
rclcpp
rclpy
Refer to #877 (comment)