[tickets] [opensaf:tickets] #2543 base: Use timeradd(), timersub() and timercmp()

2017-08-07 Thread Anders Widell via Opensaf-tickets 
- **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

2017-08-07 Thread Anders Widell via Opensaf-tickets 
- **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] #2545 dtm: osafdtmd asserts and reboots node if node up is received from known node

2017-08-07 Thread Alex Jones via Opensaf-tickets 



---

** [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

2017-08-07 Thread Alex Jones via Opensaf-tickets 
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

2017-08-07 Thread Zoran Milinkovic via Opensaf-tickets 



---

** [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] #2544 imm: saClmDispatch is returning ERR_BAD_HANDLE until immnd initializes CLM handle

2017-08-07 Thread Zoran Milinkovic via Opensaf-tickets 
- **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

[tickets] [opensaf:tickets] #2489 clm: Make it possible to select what address to present in the CLM node

2017-08-07 Thread Anders Widell via Opensaf-tickets 
- **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