Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1587957 - DPDK: vswitchd failure logs with osp10 & ovs29 can be ignored at the start of deployment
DPDK: vswitchd failure logs with osp10 & ovs29 can be ignored at the start of...
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
unspecified Severity unspecified
: async
: 10.0 (Newton)
Assigned To: Saravanan KR
Amit Ugol
: Triaged, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-06-06 06:46 EDT by Saravanan KR
Modified: 2018-06-13 13:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
During the start of the deployment with ovs2.9, the OVS-DPDK is enabled using first-boot before applying the kernel arguments and rebooting. This will cause vswitchd service to fail initially, but later when the kernel arguments are applied and the node has been rebooted, vswtichd will run as expected with DPDK enabled. The failure messages at the initial stage before the reboot can be ignored.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-06 06:56:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saravanan KR 2018-06-06 06:46:23 EDT
From ovs2.7 onwards, vswitchd will be restarted when dpdk-init
flag is set to true. In the current version of the first-boot, we are
enabling dpdk before setting the kernel args and reboot. So, huge
pages will not be available. It will fail the vswitchd restart during
the dpdk-init.

But later when kernel args are applied and rebooted, it will all work
fine. And all the ovs configurations will be applied correctly. But
this causes atleast a few set of logs related to vswtichd failure
before the restart. Though this does not harm, we need to be aware of
this behavior as analyzing logs will create questions around it.

Note You need to log in before you can comment on or make changes to this bug.