This issue is as far as I could see a bug. In other campaign sequences SMF will
wait with rebootTimeout before doing any operation after reboot. In this
campaign sequence the first operation type after a reboot was to to a CLI
command on a payload node. This timed out because the CLI command is not
wrapped in a retry using the rebootTimeout of SMF.
SMF does not keep track of all nodes after a cluster reboot therefore the
mechanism for handling a cluster reboot is to wrap any operations that is done
after a reboot in a retry loop.
---
** [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:** Wed Jun 21, 2017 03:58 AM 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
