Hi Rafael,
It's under SmfCliCommandAction::execute() => getNodeDestination(n, &nodeDest,
NULL, -1).
-1 was passed as maxWaitTime which means 20 seconds timeout will be used.
For a rolling upgrade procedure, this should be OK sine we already wait for the
node but for cluster reboot procedure, the similar thing does not happen.
/Tai
---
** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not
enough**
**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Mon Jun 19, 2017 06:14 PM UTC
**Owner:** nobody
We're now using a hard coded timeout value (20 seconds) in getting node
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller
may come up first and continue the campaign without waiting for the rest to be
up.
This can make the getNodeDestination() fail sometimes, especially for a large
cluster.
In our case, it needs 3 more seconds.
I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g:
smfRebootTimeout.
/Tai
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
