"Mooney, Sean K" <sean.k.moo...@intel.com> writes: > So just from a deployment tools point of view I would like to point out that > This change could break existing workflow that deploy ovs in a docker > container. > Kolla ansible assumes that if the docker ovs_vswitchd container is > still running that the > is infact running in dpdk mode when we set dpdk-init=true.
Is there a way to test this out and see the behavior? It does seem strange that for a possible configuration error we abort() running the vswitchd (and with --monitor set, it will continue to abort() over and over - so I guess you're also not using the monitor thread?). In the case that an abort does happen, does the Kolla script distinguish between issues where dpdk setup failed vs. some other software issue? > Can I request that if you make this change you add something along the lines > of > dpdk-init-is-fatal=true/false so that we can explicitly say which behavior we > want. > I would not be surprised if people have built monitoring around "is > the ovs-vswitchd running" I think they have, but I don't know that they use it to infer such low-level details (meaning a crash implies that dpdk configuration is wrong). > To infer at least at a highlevel that "everything is fine" where as > the log message/db field proposed > Here will invalidate that. I've added Assaf Mueller from our Open Stack team as well - maybe he has some additional details on those mechanisms outside of Kolla (maybe it exists in some kind of director / other software too, as you point out). > it would be ease to check that field but its work that needs to be > done in multiple places. I think such a knob wouldn't be useful. I believe it would either have to be defaulted to 'dpdk-init-is-fatal=true' to abort on failure (which most users would want to change making it an undesirable default), or the Kolla ansible scripts (and other detection mechanisms for dpdk failure - if they exist) would need to change. Maybe there's another approach, though? >> -----Original Message----- >> From: Aaron Conole [mailto:acon...@redhat.com] >> Sent: Thursday, April 5, 2018 10:23 PM >> To: d...@openvswitch.org >> Cc: Stokes, Ian <ian.sto...@intel.com>; Kevin Traynor >> <ktray...@redhat.com>; Ilya Maximets <i.maxim...@samsung.com>; Loftus, >> Ciara <ciara.lof...@intel.com>; Mooney, Sean K >> <sean.k.moo...@intel.com>; Terry Wilson <twil...@redhat.com> >> Subject: [RFC 0/2] dpdk: minor refactor of the initialization step >> >> Sometimes, DPDK initialization can fail, but ovs-vswitchd will abort in >> that case. When that occurs, ovs-vswitchd will be restarted by the >> monitor and immediately abort. This is rather unfriendly to users, who >> would prefer to possibly correct the issue or at least, not have lots >> of processes continually spawning. >> >> This series accepts that rte_eal_init() can and does fail for real. It >> reflects the initialization status in the database, as well as adding >> the DPDK version (where appropriate). >> >> Submitted as RFC to spawn discussion around the type to reflect for the >> initialized information. Presented here as a boolean - however, it >> might be more interesting to be a 'string' and have more elaborate >> details (ex: 'failed - ovs_strerror(rte_errno)' or 'uninitialized' or >> 'initialized'). >> >> Aaron Conole (2): >> dpdk: allow init to fail >> dpdk: reflect status and version in the database >> >> lib/dpdk-stub.c | 10 ++++++++++ >> lib/dpdk.c | 31 +++++++++++++++++++++++++------ >> lib/dpdk.h | 3 ++- >> vswitchd/bridge.c | 5 +++++ >> vswitchd/vswitch.ovsschema | 11 ++++++++--- >> vswitchd/vswitch.xml | 11 +++++++++++ >> 6 files changed, 61 insertions(+), 10 deletions(-) >> >> -- >> 2.14.3 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
