After headless, config_get_su() has already did a wrong mapping, and
su_add_to_model() also updated this wrong mapping to IMM.
After calling config_get_su after headless, the only right mapping only exists
in the sync information where amfd retrieves from avd_susi_recreate(). But this
is also where the problem came, that causes one node is mapped to two different
SU(s) (as in earlier example). The fact that we can not completely rely on
avd_susi_recreate() to update the mapping since some of nodes could be still
Attached file is a patch of approach (2), it removes the mapping update in
avd_susi_recreate(), it can avoid duplicated mapping which causes coredump. But
the su/node mapping has already been different to what it was before headless.
May this shuffle of su/node mapping after headless that causes any other
(2.4 kB; text/x-patch)
** [tickets:#2112] amfd: multiple SUs incorrectly assigned to single node**
**Created:** Tue Oct 11, 2016 11:56 PM UTC by Gary Lee
**Last Updated:** Fri Oct 14, 2016 07:18 AM UTC
**Owner:** Minh Hon Chau
Multiple SUs are assigned to a single node after SC absence.
0) load nwayactive demo
1) stop SCs
2) restart SCs
The following is observed:
root@SC-1:~# immlist safSu=SU4,safSg=AmfDemo,safApp=AmfDemo2
root@SC-1:~# immlist safSu=SU2,safSg=AmfDemo,safApp=AmfDemo2
SU2 is indeed assigned to PL-4, but SU4 was assigned to one of the SCs and is
not assigned to PL-4.
Operations on SU4 will lead to a crash of amfnd on PL-4.
Sent from sourceforge.net because firstname.lastname@example.org 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