-
Notifications
You must be signed in to change notification settings - Fork 86
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
problems on using a topology #471
Comments
I can reproduce this. Just changing node names to have something I understand
with this I have no problem reaching two levels deep (b[1-4]) but I can't seem to reach any of the d nodes three levels deep. We can see in debug level that the |
running with
and one of the deeper gw (b2)
So from the second log we can see the command actually ran successfully, just couldn't come up because of the failure. I've fixed that error in |
Hi Dominique, many thanks for this fix. It works - great. |
Intermediate gateways create a TreeWorker with a topology passed by the parent node and a new root node, and instantiate their own PropagationNodeRouter object. When such TreeWorker is scheduled, we should set the task's default router from it properly. The error seen was: ... File "ClusterShell/Propagation.py", line 411, in ev_close self.task.router.mark_unreachable(gateway) AttributeError: 'NoneType' object has no attribute 'mark_unreachable' Fixes cea-hpc#471
Intermediate gateways create a TreeWorker with a topology passed by the parent node and a new root node, and instantiate their own PropagationNodeRouter object. When such TreeWorker is scheduled, we should set the task's default router from it properly. The error seen was: ... File "ClusterShell/Propagation.py", line 411, in ev_close self.task.router.mark_unreachable(gateway) AttributeError: 'NoneType' object has no attribute 'mark_unreachable' Fixes #471
when trying to contact nodes via a topology configuration I have problems especially with a deeper nested topology.
While a flat topology seems to work.
Example topology file 'topo':
[routes]
n061901: n061902,n062001
n061902: n062002,n143501
n062001: n183601,n192201
n062002: n193201,n072602
n143501: n072701,n072702
n183601: n072801,n072802
n192201: n072901,n072902
N=n061901,n061902,n062001,n061902,n062002,n143501,n062001,n183601,n192201,n062002,n193201,n072602,n143501,n072701,n072702,n183601,n072801,n072802,n192201,n072901,n072902
clush -w $N --topology=topo hostname
^Cn061902: n061902
n061901: n061901
n062001: n062001
n062002: n062002
n143501: n143501
n192201: n192201
n183601: n183601
Keyboard interrupt.
(the interrupt is needed because it hangs for ever)
The tree in the debug looks like this:
n061901
|- n061902
| |- n062002
| |
- n[072602,193201] |
- n143501|
- n[072701-072702]
- n062001|- n183601
|
- n[072801-072802]
- n192201`- n[072901-072902]
Maybe I am doing something wrong. Has anyone an idea what is going wrong?
(every node listed above has been checked for ssh connection to each other)
With a more flat topology I see no problems:
[routes]
n061901: n061902,n062001,n062002
n061902: n143501,n183601,n192201,n193201
n062001: n072801,n072802,n072901,n072902
n062002: n072602,n072701,n072702
clush -w $N --topology=topo hostname
n061902: n061902
n061901: n061901
n062002: n062002
n062001: n062001
n193201: n193201
n192201: n192201
n072602: n072602
n072701: n072701
n072702: n072702
n183601: n183601
n143501: n143501
n072902: n072902
n072801: n072801
n072901: n072901
n072802: n072802
Thank you
Bernd
The text was updated successfully, but these errors were encountered: