API changes to sync with one Participant per Context change in rmw_fastrtps #106

ivanpauno · 2020-02-28T21:14:35Z

hidmic

Looks reasonable to me, but I'd like @eboasson to chime in too. Particularly, when we can expect them to implement recent node-to-participant mapping changes.

eboasson · 2020-03-06T11:52:40Z

It certainly looks perfectly reasonable to me. The answer to @hidmic's question is a bit more difficult: this involves a few rather large pull requests and we need to first figure out what changes are actually needed. The change to using a single participant is trivial, it is the bit that relates to introspection that is less obvious.

Currently, the Cyclone RMW layer just queries its discovery data on demand and otherwise ignores all changes save for triggering the graph guard condition. I guess it will now have to call functions in rmw_dds_common for each change, shuttle the new discovery topics back-and-forth, and forward the introspection operations to it. How much work those changes will be I don't know without having a good look at the interfaces.

So the only thing I can say definitively is that it we'll be looking into the details and hope to be able to this soon.

ivanpauno · 2020-03-06T12:41:31Z

The change to using a single participant is trivial, it is the bit that relates to introspection that is less obvious.

Yes, completly agreed.

How much work those changes will be I don't know without having a good look at the interfaces.

Please, let me know if I can help, or if anything has to be modified in rmw_dds_common to make it more suitable for cyclonedds.

So the only thing I can say definitively is that it we'll be looking into the details and hope to be able to this soon.

Great, thanks!

hidmic

I left some comments. This is a bit larger than I recall. @eboasson mind to take a look too?

rmw_cyclonedds_cpp/src/rmw_node.cpp

hidmic · 2020-03-25T21:08:26Z

rmw_cyclonedds_cpp/src/rmw_node.cpp

+    goto fail_alloc;
+  }
+  size_t i;
+  i = 0;


@ivanpauno nit: last two lines can be collapsed into one.

Same as above, it comes from rmw_get_node_names.

There is a pretty fun reason: when done in the same line, the compiler fails saying that the above goto is skipping an initialization. In general, it's safe to skip the initialization of a trivially destructible object (AFAIU), but the compiler shows the warning anyways (and we transform that warning in an error, because of our compiler flags).

When split in two lines, the compiler doesn't show a warning.

P.S.: This kind of warning never happens in pure C code, it only applies when you use C++.

Hmm interesting, odd but interesting.

Please define ‘i’ higher in the scope to avoid this instead. This what is done in all the other functions that use goto.

I think @wjwwood comment still applies.

The code is pre-existent, and I don't want to retrigger CI because of this. If you don't mind, I will ignore the comment.

rmw_cyclonedds_cpp/src/rmw_node.cpp

hidmic

I think rmw_get_nodes_names* API implementation is improving, but it needs some adjustment.

hidmic · 2020-03-27T20:54:06Z

rmw_cyclonedds_cpp/src/rmw_node.cpp

+{
+  if (RMW_RET_OK != rmw_check_zero_rmw_string_array(security_contexts)) {
+    return RMW_RET_ERROR;
+  }


@ivanpauno is it invalid to call rmw_get_node_names_with_security_contexts() with a null security_contexts? If not, I think this check should be relocated to the implementation function and conditionally executed based on security_contexts value.

In rmw_get_node_names_impl security_contexts can be NULL.
In rmw_get_node_names_with_security_contexts security_contexts cannot be NULL.

I think the current logic is fine.

rmw_cyclonedds_cpp/src/rmw_node.cpp

ivanpauno · 2020-03-31T13:56:00Z

I closed and reopened to trigger the new checks.

ivanpauno · 2020-03-31T18:53:48Z

@rotu the check called ubuntu-18,04, eloquent seems to be using master and not eloquent.

Also, it's impossible that the checks using master would ever pass, if it's not possible to specify a branch in other repository where we're doing simultaneous changes (e.g. rmw).
That's because we bump the rmw version the first time the API is changed after a release, but not again until next release.

I'm not completely sure how to solve the problem, but I think we should only have actions for checking compatibility with past releases, and just rely on CI for master (which should be run manually by the user when the PR is ready).

P.S.: Having github actions for this is great, thanks for adding them!

ivanpauno · 2020-03-31T19:03:31Z

@rotu the check called ubuntu-18,04, eloquent seems to be using master and not eloquent.

Sounds like #133 fixed this.
But checks checking source (which I understand is master), will continue failing.

rotu · 2020-03-31T19:08:36Z

@ivanpauno I'm aware of the issue and it's due to my mistake in setting this up. Should be fixed by #133.

Yes, the checks ONLY check changes in this repo - the goal is to prevent accidental breakage. A change like this PR, involving a constellation of different commits across repos that do not move in lock-step, does break things and presents a versioning challenge. Assuming that it would be too burdensome to preserve compatibility, the answer is to merge it with these checks failing.

rotu · 2020-03-31T19:14:59Z

FYI: here's me blundering through setting up CI. Using "source" was a mistake. ros-tooling/action-ros-ci#120

ivanpauno · 2020-03-31T19:18:38Z

Yes, the checks ONLY check changes in this repo - the goal is to prevent accidental breakage. A change like this PR, involving a constellation of different commits, does tend to break things and presents a versioning challenge. Assuming that it would be too burdensome to preserve compatibility, the answer is to merge it with these checks failing.

That sounds good to me.

I know that the actions usingsource will fail in this PR, but I would like to see if I'm maintaining compatibility with dashing and eloquent correctly.
Of course, I can manually run CI for dashing and eloquent, but that's what usually people don't do and end up breaking them.

Most of the PRs that have broken dashing and eloquent builds were merged with simultaneous changes in rmw, so ignoring the checks in those cases is ignoring the cases where we are most likely to break previous releases 😄 .

To avoid ignoring the result of the checks in those cases, I think we should either:

Continue running eloquent and dashing checks if source check fails (i.e. not cancelling them).
Delete the source checks, and rely on manually ran CI for master.

rotu · 2020-03-31T19:28:29Z

* Continue running `eloquent` and `dashing` checks if `source` check fails (i.e. not cancelling them).

Agreed. That should be the behavior since #133 (the setting fail-fast: false in the yml)

Delete the source checks, and rely on manually ran CI for master.

Manually run CI is still part of the picture. The actions in this repo only check things up to rmw_cyclonedds. It would certainly be nice to test things upstream as well with GitHub Actions and add more tests to this repo, testing both correctness and performance.

rotu · 2020-03-31T23:13:40Z

To rerun this against latest CI workflow, I think you need to rebase onto master. I think if you fork this repo on Github, you can simply enable CI in the Actions tab of your fork and it will run on every push.

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

…curity_contexts Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

hidmic

LGTM

rmw_cyclonedds_cpp/src/rmw_node.cpp

hidmic · 2020-04-02T13:45:50Z

rmw_cyclonedds_cpp/src/rmw_node.cpp

+    goto fail_alloc;
+  }
+  size_t i;
+  i = 0;


I think @wjwwood comment still applies.

ivanpauno · 2020-04-02T13:49:09Z

Note for reviewers: All checks are passing, except the ones using master. That's because there are simultaneous changes in others repos, and it's expected.

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

eboasson · 2020-04-07T13:31:30Z

@ivanpauno I've finally carved out the time to work on this, but before really commencing I wanted to make sure there won't be any duplication of work, which there might be if you happen to also be looking into it. (If you are, I'm totally happy to leave you to it, by the way 😁)

Also looking at the scope of the changes, and as I have mentioned before, I think this is the point where we should stop providing compatibility with dashing and eloquent in rmw_cyclonedds master. Hopefully we'll be able to merge #123 into master first: that would then be a single version that supports all features and works with Dashing, Eloquent and Foxy, and so would also be valuable for anyone who needs to integrate multiple versions of ROS2 in a single system.

It'll take me some time to get all the changes done and tested locally, so I'd say there's plenty of time for updating #123 to match the current state of master and merging it.

ivanpauno · 2020-04-07T18:52:38Z

@ivanpauno I've finally carved out the time to work on this, but before really commencing I wanted to make sure there won't be any duplication of work, which there might be if you happen to also be looking into it. (If you are, I'm totally happy to leave you to it, by the way grin)

Sounds good to me.
I'm not currently working on migrating the remaining rmw implementations to use one Participant per Context, neither I'm allocated to do it in a near future.

Also looking at the scope of the changes, and as I have mentioned before, I think this is the point where we should stop providing compatibility with dashing and eloquent in rmw_cyclonedds master.

100% agreed, creating a new branch makes sense.

Hopefully we'll be able to merge #123 into master first: that would then be a single version that supports all features and works with Dashing, Eloquent and Foxy, and so would also be valuable for anyone who needs to integrate multiple versions of ROS2 in a single system.

Sounds great to me!

If you need any reviews or if you have any questions, let me know, and I will be willing to help.
I will update ros2/design#250 soon, so it better reflects what was done in rmw_fastrtps.

ivanpauno added the in review label Feb 28, 2020

ivanpauno requested review from wjwwood and hidmic February 28, 2020 21:14

ivanpauno self-assigned this Feb 28, 2020

ivanpauno mentioned this pull request Mar 3, 2020

Modify implementations to use one Participant per Context ros2/rmw#183

Closed

6 tasks

hidmic approved these changes Mar 3, 2020

View reviewed changes

ivanpauno changed the title ~~Rename rmw_node_security_options_t to rmw_security_options_t~~ API changes to sync with one Participant per Context change in rmw_fastrtps Mar 4, 2020

ivanpauno force-pushed the ivanpauno/one-participant-per-context branch from 118119f to ad48796 Compare March 23, 2020 16:39

ivanpauno requested a review from hidmic March 25, 2020 17:54

hidmic reviewed Mar 25, 2020

View reviewed changes

ivanpauno requested a review from hidmic March 26, 2020 18:26

ivanpauno force-pushed the ivanpauno/one-participant-per-context branch from 0dc9edd to 429cd7e Compare March 27, 2020 12:57

hidmic reviewed Mar 27, 2020

View reviewed changes

ivanpauno requested a review from hidmic March 31, 2020 13:02

ivanpauno closed this Mar 31, 2020

ivanpauno reopened this Mar 31, 2020

ivanpauno closed this Mar 31, 2020

ivanpauno reopened this Mar 31, 2020

ivanpauno force-pushed the ivanpauno/one-participant-per-context branch from e09008b to deb1957 Compare March 31, 2020 23:00

ivanpauno closed this Mar 31, 2020

ivanpauno reopened this Mar 31, 2020

ivanpauno added 13 commits April 1, 2020 09:34

Rename rmw_node_security_options_t to rmw_security_options_t

b9e332a

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Use conditional logic to not break previous versions

a74be96

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Add rmw_use_node_name_in_security_directory_lookup

095c2a3

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Latest update after discussion about supporting sros2

db846a2

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Naming: replace context_name with security_context

3d038c0

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Add security_context info to participant user data

49e9e9f

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Correct errors after testing

53e42ee

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Add contional compilation guards

3c54139

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Address reviewer's comment

5a5e5bf

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Please cpplint

b1ac746

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Fix error

c3596ee

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Use common code for rmw_get_node_names and rmw_get_node_names_with_se…

bac4a25

…curity_contexts Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Address peer review comments

cc48725

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

ivanpauno force-pushed the ivanpauno/one-participant-per-context branch from deb1957 to cc48725 Compare April 1, 2020 12:34

Fix compatibility issues with Dashing and Eloquent

1e8df69

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

ivanpauno mentioned this pull request Apr 2, 2020

Switch to one Participant per Context ros2/rmw_fastrtps#312

Merged

hidmic approved these changes Apr 2, 2020

View reviewed changes

Address peer review comments

d213440

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

ivanpauno merged commit 216211e into master Apr 3, 2020

delete-merged-branch bot deleted the ivanpauno/one-participant-per-context branch April 3, 2020 13:13

mikaelarguedas mentioned this pull request Apr 5, 2020

Enable use of Cyclone DDS security features #123

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

API changes to sync with one Participant per Context change in rmw_fastrtps #106

API changes to sync with one Participant per Context change in rmw_fastrtps #106

ivanpauno commented Feb 28, 2020

hidmic left a comment

eboasson commented Mar 6, 2020

ivanpauno commented Mar 6, 2020

hidmic left a comment

hidmic Mar 25, 2020

ivanpauno Mar 26, 2020

ivanpauno Mar 27, 2020

hidmic Mar 27, 2020

wjwwood Mar 27, 2020

hidmic Apr 2, 2020 •

edited

Loading

ivanpauno Apr 2, 2020

hidmic left a comment

hidmic Mar 27, 2020

ivanpauno Mar 27, 2020

ivanpauno commented Mar 31, 2020

ivanpauno commented Mar 31, 2020 •

edited

Loading

ivanpauno commented Mar 31, 2020

rotu commented Mar 31, 2020 •

edited

Loading

rotu commented Mar 31, 2020

ivanpauno commented Mar 31, 2020

rotu commented Mar 31, 2020

rotu commented Mar 31, 2020

hidmic left a comment

hidmic Apr 2, 2020 •

edited

Loading

ivanpauno commented Apr 2, 2020

eboasson commented Apr 7, 2020

ivanpauno commented Apr 7, 2020

API changes to sync with one Participant per Context change in rmw_fastrtps #106

API changes to sync with one Participant per Context change in rmw_fastrtps #106

Conversation

ivanpauno commented Feb 28, 2020

hidmic left a comment

Choose a reason for hiding this comment

eboasson commented Mar 6, 2020

ivanpauno commented Mar 6, 2020

hidmic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hidmic Apr 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hidmic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanpauno commented Mar 31, 2020

ivanpauno commented Mar 31, 2020 • edited Loading

ivanpauno commented Mar 31, 2020

rotu commented Mar 31, 2020 • edited Loading

rotu commented Mar 31, 2020

ivanpauno commented Mar 31, 2020

rotu commented Mar 31, 2020

rotu commented Mar 31, 2020

hidmic left a comment

Choose a reason for hiding this comment

hidmic Apr 2, 2020 • edited Loading

Choose a reason for hiding this comment

ivanpauno commented Apr 2, 2020

eboasson commented Apr 7, 2020

ivanpauno commented Apr 7, 2020

hidmic Apr 2, 2020 •

edited

Loading

ivanpauno commented Mar 31, 2020 •

edited

Loading

rotu commented Mar 31, 2020 •

edited

Loading

hidmic Apr 2, 2020 •

edited

Loading