[tickets] [opensaf:tickets] #2489 clm: Make it possible to select what address to present in the CLM node
- **status**: review --> fixed - **Comment**: commit 7a2c7021b2f08136e325a159851e113e63d3e0fe (HEAD -> develop, origin/develop, ticket-2489) Author: Anders Widell Date: Fri Aug 4 13:56:06 2017 +0200 clm: Include boot time and node address in join request message [#2489] The node join request message now has two new fields: boot time and node address. This allows us to provide more accurate and correct information in the CLM node runtime attributes in the information model: * The boot time field transmits the node's actual boot time to the CLM server. Previously, the node join time was used as an approximation of the node boot time, but this might be inaccurate or incorrect. For example, if OpenSAF was started much later than the node was booted (e.g. if OpenSAF was restarted without a node reboot), then the node join time will differ significantly from the node boot time. * The node address field transmits the node address to be presented to the application through the information model. Previously, the IP address which was used by OpenSAF internal communication was presented as the one and only node address, and there was no way to select some other address in case the node has multiple network addresses. The application now has the possibility to select which network address to present in the information model. --- ** [tickets:#2489] clm: Make it possible to select what address to present in the CLM node** **Status:** fixed **Milestone:** 5.17.10 **Created:** Thu Jun 08, 2017 11:11 AM UTC by Anders Widell **Last Updated:** Mon Jul 31, 2017 01:11 PM UTC **Owner:** Anders Widell A simpler solution for the problem described in ticket [#2479] is to let the user configure what address CLM shall show in the saClmNodeCurrAddress attribute. The following use cases will all be covered by this simpler solution: * OpenSAF is configured to use IP, but the application is using TIPC and needs to know the TIPC address of the node. Or vice versa. * Both the application and OpenSAF are configured to use IP, but later on we wish to re-configure OpenSAF to use TIPC, *without* affecting the application or exposing this change in the saClmNodeCurrAddress attribute. * Both the application and OpenSAF are configured to use IP (and the same network), but later on we wish to introduce a separate IP network dedicated to OpenSAF internal communication. The application is supposed to continue using the same IP network as before, and is *not* allowed to use the new network which is dedicated to OpenSAF internal communication only. As shown in these use cases, the application is really only interested in knowing one address for each node. The problem we need to solve is that a node can have many addresses and we need to be able to select which one to present through the CLM interface. --- 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
[tickets] [opensaf:tickets] #2543 base: Use timeradd(), timersub() and timercmp()
- **status**: unassigned --> wontfix - **assigned_to**: Anders Widell - **Milestone**: 5.17.10 --> never - **Comment**: Although the system does provide the mentioned functions, there seems to be very little benefit to use them instead of using the very similar functions already implemented in OpenSAF. The OpenSAF variants have the advantage of being inline functions, which provide better type safety compared to the macros defined in the system header files. --- ** [tickets:#2543] base: Use timeradd(), timersub() and timercmp()** **Status:** wontfix **Milestone:** never **Created:** Wed Aug 02, 2017 11:38 AM UTC by Anders Widell **Last Updated:** Wed Aug 02, 2017 11:38 AM UTC **Owner:** Anders Widell The system header file sys/time.h defines macros timeradd(), timersub() and timercmp() with similar functionality as some of the OpenSAF time support functions. The macros from the system header files could be used instead of the OpenSAF ones. --- 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
[tickets] [opensaf:tickets] #2538 clm: Provide the node address as a parameter to the scale-out script
- **status**: review --> fixed - **Comment**: commit eef6c36d0e7b7447f7ebd3261a7503a37331f8e5 (HEAD -> develop, origin/develop, ticket-2538) Author: Anders Widell Date: Mon Aug 7 14:09:48 2017 +0200 clm: Provide the node address as a parameter to the scale-out script [#2538] Provide the node address as a command-line parameter when calling the scale-out script. This can be useful if the scale-out script needs to contact the node (e.g. copy some files to it or update some configuration on the node's local disk) as part of the scale-out operation. --- ** [tickets:#2538] clm: Provide the node address as a parameter to the scale-out script** **Status:** fixed **Milestone:** 5.17.10 **Created:** Mon Jul 31, 2017 01:31 PM UTC by Anders Widell **Last Updated:** Tue Aug 01, 2017 11:15 AM UTC **Owner:** Anders Widell Provide the node address as a command-line parameter when calling the scale-out script. This can be useful if the scale-out script needs to contact the node (e.g. copy some files to it or update some configuration on the node's local disk) as part of the scale-out operation. The node address can also be needed e.g. to open up the firewall. --- 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
[tickets] [opensaf:tickets] #2544 imm: saClmDispatch is returning ERR_BAD_HANDLE until immnd initializes CLM handle
--- ** [tickets:#2544] imm: saClmDispatch is returning ERR_BAD_HANDLE until immnd initializes CLM handle** **Status:** accepted **Milestone:** 5.17.10 **Created:** Mon Aug 07, 2017 02:08 PM UTC by Zoran Milinkovic **Last Updated:** Mon Aug 07, 2017 02:08 PM UTC **Owner:** Zoran Milinkovic In the poll loop, immnd handles FD_CLM event even if FD_CLM event is not processed by poll call. With random values in fds[FD_CLM], immnd may process FD_CLM event without calling poll. saClmDispatch will return SA_AIS_ERR_BAD_HANDLE error until CLM handle is initialized and CLM selection object set to immnd_cb->clmSelectionObject. --- 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
[tickets] [opensaf:tickets] #2545 dtm: osafdtmd asserts and reboots node if node up is received from known node
--- ** [tickets:#2545] dtm: osafdtmd asserts and reboots node if node up is received from known node** **Status:** accepted **Milestone:** 5.17.10 **Created:** Mon Aug 07, 2017 02:27 PM UTC by Alex Jones **Last Updated:** Mon Aug 07, 2017 02:27 PM UTC **Owner:** Alex Jones Topology is two physical nodes, and 10-15 VMs on each physical node in a KVM setup. OVS 2.7 is used as the bridging between the host and VMs on each physical node. And OVN is used for internode networking between the two hosts, using geneve tunnel. MTU on the physical tunnel ports is 1500 as are VM interfaces. You also need a fairly large IMM database. This will ensure that 1500 byte packets will be sent from the controller during IMM sync. Packets larger than 14xx bytes will be dropped by the tunnel, resulting in missed packets on the other side. When a node across the tunnel tries to come into the cluster, dtmd on this new node will miss some packets because they are dropped by the tunnel (because MTU is too large). This will cause dtmd on that node to assert and reboot continuously. Thus, it never comes into the cluster. Setting MTU of the tunnel to be 9000 (jumbo frames) makes this problem go away because packets are no longer being dropped due to MTU size. You could probably reproduce this without using any virtualization -- just communication between nodes over a tunnel where the MTU across the path is less than the MTU of the interfaces of the OpenSAF nodes themselves. --- 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
[tickets] [opensaf:tickets] #2545 dtm: osafdtmd asserts and reboots node if node up is received from known node
Jul 31 16:33:23.479339 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node.c:0679] TR DTM :Listening socket is readable Jul 31 16:33:23.479352 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_sockets.c:1480] >> dtm_process_accept Jul 31 16:33:23.479370 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_sockets.c:0079] >> set_keepalive Jul 31 16:33:23.479383 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_sockets.c:0154] << set_keepalive: rc :1 Jul 31 16:33:23.479393 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0035] >> dtm_node_new Jul 31 16:33:23.479402 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0050] << dtm_node_new Jul 31 16:33:23.479410 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0235] >> dtm_node_add Jul 31 16:33:23.479418 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0236] TR DTM:value of i 1 Jul 31 16:33:23.479427 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0260] TR DTM:Adding comm_socket to the database with comm_socket :32 as key Jul 31 16:33:23.479435 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0297] << dtm_node_add: rc : 1 Jul 31 16:33:23.479444 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0235] >> dtm_node_add Jul 31 16:33:23.479452 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0236] TR DTM:value of i 2 Jul 31 16:33:23.479460 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0277] TR DTM:Adding node_ip to the database with node_ip :10.250.1.1 as key Jul 31 16:33:23.479469 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0284] TR DTM:ncs_patricia_tree_add for node_ip FAILED for :10.250.1.1 :2 Jul 31 16:33:23.479477 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0297] << dtm_node_add: rc : 2 Jul 31 16:33:23.479503 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_sockets.c:1572] ER DTM: dtm_node_add failed .node_ip: 10.250.1.1, node_id: 0 Jul 31 16:33:23.479513 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_sockets.c:0393] >> dtm_comm_socket_close Jul 31 16:33:23.479522 osafdtmd [39805:39809:src/dtm/dtmnd/dtm_node_db.c:0204] >> dtm_node_get_by_comm_socket --- ** [tickets:#2545] dtm: osafdtmd asserts and reboots node if node up is received from known node** **Status:** accepted **Milestone:** 5.17.10 **Created:** Mon Aug 07, 2017 02:27 PM UTC by Alex Jones **Last Updated:** Mon Aug 07, 2017 02:27 PM UTC **Owner:** Alex Jones Topology is two physical nodes, and 10-15 VMs on each physical node in a KVM setup. OVS 2.7 is used as the bridging between the host and VMs on each physical node. And OVN is used for internode networking between the two hosts, using geneve tunnel. MTU on the physical tunnel ports is 1500 as are VM interfaces. You also need a fairly large IMM database. This will ensure that 1500 byte packets will be sent from the controller during IMM sync. Packets larger than 14xx bytes will be dropped by the tunnel, resulting in missed packets on the other side. When a node across the tunnel tries to come into the cluster, dtmd on this new node will miss some packets because they are dropped by the tunnel (because MTU is too large). This will cause dtmd on that node to assert and reboot continuously. Thus, it never comes into the cluster. Setting MTU of the tunnel to be 9000 (jumbo frames) makes this problem go away because packets are no longer being dropped due to MTU size. You could probably reproduce this without using any virtualization -- just communication between nodes over a tunnel where the MTU across the path is less than the MTU of the interfaces of the OpenSAF nodes themselves. --- 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
[tickets] [opensaf:tickets] #2544 imm: saClmDispatch is returning ERR_BAD_HANDLE until immnd initializes CLM handle
- **status**: accepted --> review - **Comment**: https://sourceforge.net/p/opensaf/mailman/message/35985521/ --- ** [tickets:#2544] imm: saClmDispatch is returning ERR_BAD_HANDLE until immnd initializes CLM handle** **Status:** review **Milestone:** 5.17.10 **Created:** Mon Aug 07, 2017 02:08 PM UTC by Zoran Milinkovic **Last Updated:** Mon Aug 07, 2017 02:08 PM UTC **Owner:** Zoran Milinkovic In the poll loop, immnd handles FD_CLM event even if FD_CLM event is not processed by poll call. With random values in fds[FD_CLM], immnd may process FD_CLM event without calling poll. saClmDispatch will return SA_AIS_ERR_BAD_HANDLE error until CLM handle is initialized and CLM selection object set to immnd_cb->clmSelectionObject. --- 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