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<mailto:Matt.Peters@windriver.com>> Cc: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>; Zhao, Forrest <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>; Khalil, Ghada <Ghada.Khalil@windriver.com<mailto: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<mailto:chenjie.xu@intel.com>> Cc: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>; Zhao, Forrest <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>; Khalil, Ghada <Ghada.Khalil@windriver.com<mailto: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<mailto:chenjie.xu@intel.com>> Date: Monday, September 16, 2019 at 11:32 PM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>>, "Zhao, Forrest" <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>, Ghada Khalil <Ghada.Khalil@windriver.com<mailto: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