Ulrich,

Hi!

A short notification:

I had set up a new cluster using udpu, finding that ringnumber 0 has a ttl statement 
("ttl:    1"), but ringnumber 1 had not. So I added one for ringnumber 1, and 
then I reloaded corosync via  corosync-cfgtool -R.

probably ttl with value different from 1 right?

Amazingly when (re)starting corosync, it failed with:
Nov 19 15:29:51 h18 corosync[90724]:   [MAIN  ] parse error in config: Can only 
set ttl on multicast transport types

Yeah, old reload was quite flaky. 3.1.0 has way improved reload so it would return error when config parsing or sanity checks failed.


Independent of whether this may be true or not, it would be nice if it were 
handled consistently.

What you mean by "handled consistently"? Code is checking if transport != UDP (so multicast) and if ttl != 1 -> display error.

Preferrably "ttl" would be just ignored with warning when not using multicast.

That doesn't sound like a good idea. User set something and may expect that something is applied.

It may make sense to consider adding ttl support for other transports.

Regards,
  honza


Regards,
Ulrich




_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/


_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Reply via email to