Hi Matt,

Thank you for your feedback! Capture the new item under the existing Storyboard is ok to me.

Best Regards,

Xu, Chenjie

From: Peters, Matt [mailto:Matt.Peters@windriver.com]
Sent: Friday, September 20, 2019 2:25 AM
To: Xu, Chenjie <chenjie.xu@intel.com>
Cc: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io>; Zhao, Forrest <forrest.zhao@intel.com>; Khalil, Ghada <Ghada.Khalil@windriver.com>
Subject: Re: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Chenjie,

That would definitely be nice to have since this is not currently covered by any link monitoring. However, the K8s SRIOV Device Plugin will monitor the link state and only include devices that are in an UP state. Unfortunately, this does not cover the scenario of the device or link going down after it has been scheduled and is in use. I think we should capture this as a secondary task.

Did you want to capture this item as a new task under the existing Storyboard? If not, I can create a new one to track this.

The best way to monitor sriov data interfaces would be to update the lmon (link monitor) to include the additional data interfaces. Currently lmon obtains the list of interfaces from /etc/platform/platform.conf which only has the platform interfaces. To expand on this, I would propose that we create a specific configuration file for lmon to consume that would include the list of all interfaces that need to be monitored, including the association of network assignment. This would avoid having the association done by lmon and it would be populated explicitly by Puppet from the stored system inventory data.

-Matt

From: "Xu, Chenjie" <chenjie.xu@intel.com>
Date: Thursday, September 19, 2019 at 11:39 AM
To: "Peters, Matt" <Matt.Peters@windriver.com>
Cc: "'starlingx-discuss@lists.starlingx.io'" <starlingx-discuss@lists.starlingx.io>, "Zhao, Forrest" <forrest.zhao@intel.com>, Ghada Khalil <Ghada.Khalil@windriver.com>
Subject: Re: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Matt,

One more question: OVS is running on openstack worker node and we can retrieve the host interface state through OVS commands. But we can’s retrieve the host interface state through OVS commands on non-openstack worker node. StarlingX will support non-openstack worker node and OVS won’t run on this kind of node. The host interfaces for datanetwork are also used in non-openstack worker node. For example: SR-IOV CNI plugin. Do we needs to cover this scenario?

Best Regards,

Xu, Chenjie

From: Xu, Chenjie
Sent: Thursday, September 19, 2019 8:05 PM
To: 'Peters, Matt' <Matt.Peters@windriver.com>
Cc: 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io>; Zhao, Forrest <forrest.zhao@intel.com>; 'Khalil, Ghada' <Ghada.Khalil@windriver.com>
Subject: RE: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Matt,

During my implementation, I have several questions as below:

1. If a port is a bond, does the related bridge also has a name with format br-phy%index?

2. If OVS-DPDK is used, is bond still supported?

3. A bond may contain multiple interfaces. Do we have some restriction on the number of interfaces belonging to a same bond?

4. How can I get the root password in StarlingX. Because it has to be root to execute OVS commands.

5. How to decide the code is running on OpenStack worker node or not.

Best Regards,

Xu, Chenjie

From: Xu, Chenjie
Sent: Wednesday, September 18, 2019 11:28 AM
To: Peters, Matt <Matt.Peters@windriver.com>
Cc: starlingx-discuss@lists.starlingx.io; Zhao, Forrest <forrest.zhao@intel.com>; Khalil, Ghada <Ghada.Khalil@windriver.com>
Subject: RE: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Matt,

Thank you for your information! I will submit a patch to implement this function.

Best Regards,

Xu, Chenjie

From: Peters, Matt [mailto:Matt.Peters@windriver.com]
Sent: Tuesday, September 17, 2019 9:32 PM
To: Xu, Chenjie <chenjie.xu@intel.com>
Cc: starlingx-discuss@lists.starlingx.io; Zhao, Forrest <forrest.zhao@intel.com>; Khalil, Ghada <Ghada.Khalil@windriver.com>
Subject: Re: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Chenjie,

Yes, the dump-ports-desc can be used to obtain the current port state and negotiated state with the peer. This data will need to be mapped back to the data interface mapping of the host so that the appropriate alarms may be raised against the proper entity.

In addition, if the data interface is a bond, the following information will also have to be retrieved in order to obtain the full state of the bond interface, including LACP information (if applicable).

ovs-appctl bond/show

ovs-appctl lacp/show

Finally, the alarming behavior should be the following:

Data port is down and does not belong to a bond – Critical Alarm

Data port(s) down, but enabled port remains in bond – Major Alarm (degraded service)

All data ports down in a bond – Critical Alarm

From: "Xu, Chenjie" <chenjie.xu@intel.com>
Date: Monday, September 16, 2019 at 11:32 PM
To: "Peters, Matt" <Matt.Peters@windriver.com>
Cc: "starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io>, "Zhao, Forrest" <forrest.zhao@intel.com>, Ghada Khalil <Ghada.Khalil@windriver.com>
Subject: [Starlingx-discuss] OVS collectd interface/port state monitoring

Hi Matt,

For task “OVS collectd interface/port state monitoring”, which parts should be monitored? For example: Bridge, Port.

https://storyboard.openstack.org/#!/story/2002948

https://bugs.launchpad.net/starlingx/+bug/1834512

Bridge "br-phy1"

Port "br-phy1"

Interface "br-phy1"

type: internal

Port "eth1"

Interface "eth1"

type: dpdk

options: {dpdk-devargs="0000:18:00.1", n_rxq="1"}

Port "lldp8a3c28ca-7f"

Interface "lldp8a3c28ca-7f"

type: internal

The command “ovs-ofctl dump-ports-desc $ovs_bridge” can be used with collectd for both OVS and OVS-DPDK. The link status for interfaces can be detected as below:

For OVS:

After pull the cabel:

controller-0:/home/sysadmin# ovs-ofctl dump-ports-desc br-phy0

OFPST_PORT_DESC reply (xid=0x2):

1(enp51s0f3): addr:0c:c4:7a:ff:5f:ef

config: 0

state: LINK_DOWN

current: COPPER AUTO_NEG

advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG AUTO_PAUSE

supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG AUTO_PAUSE

speed: 0 Mbps now, 1000 Mbps max

2(phy-br-phy0): addr:1a:0a:21:03:6a:1e

config: 0

state: 0

speed: 0 Mbps now, 0 Mbps max

LOCAL(br-phy0): addr:0c:c4:7a:ff:5f:ef

config: PORT_DOWN

state: LINK_DOWN

speed: 0 Mbps now, 0 Mbps max

After plug in the cable:

controller-0:/home/sysadmin# ovs-ofctl dump-ports-desc br-phy0

OFPST_PORT_DESC reply (xid=0x2):

1(enp51s0f3): addr:0c:c4:7a:ff:5f:ef

config: 0

state: 0

current: 1GB-FD COPPER AUTO_NEG

advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG AUTO_PAUSE

supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG AUTO_PAUSE

speed: 1000 Mbps now, 1000 Mbps max

2(phy-br-phy0): addr:1a:0a:21:03:6a:1e

config: 0

state: 0

speed: 0 Mbps now, 0 Mbps max

LOCAL(br-phy0): addr:0c:c4:7a:ff:5f:ef

config: PORT_DOWN

state: LINK_DOWN

speed: 0 Mbps now, 0 Mbps max

For OVS-DPDK:

After pull the cabel:

controller-0:/home/sysadmin# ovs-ofctl dump-ports-desc br-phy1

OFPST_PORT_DESC reply (xid=0x2):

1(eth1): addr:3c:fd:fe:da:e8:85

config: 0

state: LINK_DOWN

current: AUTO_NEG

speed: 0 Mbps now, 0 Mbps max

2(lldp8a3c28ca-7f): addr:52:97:0b:a4:ef:23

config: 0

state: 0

current: 10MB-FD COPPER

speed: 10 Mbps now, 0 Mbps max

LOCAL(br-phy1): addr:3c:fd:fe:da:e8:85

config: 0

state: 0

current: 10MB-FD COPPER

speed: 10 Mbps now, 0 Mbps max

After plug in the cable:

controller-0:/home/sysadmin# ovs-ofctl dump-ports-desc br-phy1

OFPST_PORT_DESC reply (xid=0x2):

1(eth1): addr:3c:fd:fe:da:e8:85

config: 0

state: 0

current: 10GB-FD AUTO_NEG

speed: 10000 Mbps now, 0 Mbps max

2(lldp8a3c28ca-7f): addr:52:97:0b:a4:ef:23

config: 0

state: 0

current: 10MB-FD COPPER

speed: 10 Mbps now, 0 Mbps max

LOCAL(br-phy1): addr:3c:fd:fe:da:e8:85

config: 0

state: 0

current: 10MB-FD COPPER

speed: 10 Mbps now, 0 Mbps max

Best Regards,

Xu, Chenjie