* Update upstream OVS debian packaging to be on par with package
source in Debian/Ubuntu:
- Provide a openvswitch-switch-dpdk package that integrates with
the dpdk package in the distributions so that end users can opt
into a DPDK-enabled Open vSwitch binary.
- Provide systemd service files.
- Provide openvswitch-source package for reproducible integrated
build of for example OVN.
- Stop building shared library and subsequently remove
libopenvswitch and libopenvswitch-dev binary packages.
Co-authored-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Luca Boccassi <bluca@debian.org>
Co-authored-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Co-authored-by: James Page <james.page@ubuntu.com>
Signed-off-by: James Page <james.page@ubuntu.com>
Co-authored-by: Corey Bryant <corey.bryant@canonical.com>
Signed-off-by: Corey Bryant <corey.bryant@canonical.com>
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The packaging source in the OVS repository has drifted away from
what is currently in Debian and Ubuntu. This state is problematic
because from time to time someone tries to build packages from the
upstream OVS debian package source and then expect that package to
work with up-/down-grades from-/to/ distro versions.
To support the on-going work to remove the out of tree OVS kernel
driver from the repository [0], an update to the debian packaging
is also required. On the back of the discussion in [0] we agreed
that replacing the current version with what Debian and Ubuntu
is currently converging on would be preferable.
This commit is a first in a series to update the upstream OVS
debian packaging source to be up to date with what is currently
in Debian and Ubuntu.
0: https://mail.openvswitch.org/pipermail/ovs-dev/2022-June/394634.html
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The 'openvswitch-common' package did not work well with cross-compiling
since it required Python. This package is broken into two packages as
follows:
- libopenvwitch: contains library files (.a, .so)
- openvswitch-common: depends on libopenvswitch, contains command-line
tools such as ovs-ofctl, ovs-appctl etc.
In addition, this 'openvswitch-dev' library is renamed to
'libopenvswitch-dev' to align more closely with Debian policy. It
depends on libopenvswitch.
Signed-off-by: Ben Warren <ben@skyportsystems.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Compile and package ovs shared libraries and create new header
package for debian (openvswitch-dev) and rhel (openvswitch-devel).
VMware-BZ: #1556299
Signed-off-by: Edwin Chiu <echiu@vmware.com>
Co-authored-by: Harold Lim <haroldl@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This utility was completely broken and no one noticed for the time of a
full release, so I think that's a safe sign that we should remove it.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
ovs-lib is used by both ovs-ctl and ovn-ctl. So it
is useful to move it to openvswitch-common
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
This commit makes the bash completion scripts be installed to
$(sysconfdir)/bash_completion.d/ through 'make install' and to
/etc/bash_completion.d/ through package installation. This will
make the scripts available for each bash session.
An alternative is to put scripts to /usr/share/bash_completion/
directory. However, this is not supported by earlier version of
bash completion.
Signed-off-by: Alex Wang <alexw@nicira.com>
Open vSwitch does not have native integration with Docker.
INSTALL.Docker explains how Open vSwitch can be integrated
with docker non-natively.
ovs-docker is a helper script to add network interfaces to
docker containers and to attach them as ports to OVS bridge.
This script can be further enhanced as we understand different
use cases.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The underlying glibc interface is deprecated because the interface itself
is not thread-safe. That means that there's no way for a layer on top of
it to be thread-safe.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
The new ovs-parse-backtrace utility makes the output of ovs-appctl
backtrace more human readable by removing duplicate traces and
converting addresses to function names.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This is an improvement in {ovs|xen}-bugtool archive output to determine the
version which was running for all the OVS daemons. It is implemented as a
plugin which internally calls "ovs-appctl -t <daemon> version" command for
daemons whose pid file is present in /var/run/openvswitch directory.
Feature #10383
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
[blp@nicira.com updated debian/copyright.in]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is in repsonse to the following rpmlint warnings:
W: non-conffile-in-etc /etc/openvswitch/bugtool-plugins/system-configuration/openvswitch.xml
W: non-conffile-in-etc /etc/openvswitch/bugtool-plugins/system-logs/openvswitch.xml
W: non-conffile-in-etc /etc/openvswitch/bugtool-plugins/system-configuration.xml
W: non-conffile-in-etc /etc/openvswitch/bugtool-plugins/network-status/openvswitch.xml
W: non-conffile-in-etc /etc/openvswitch/bugtool-plugins/kernel-info/openvswitch.xml
The xenserver specfile still places them in /etc/xensource/bugtool since
that's a distro policy. Of course, the rpmlint warnings are as well,
however, this seems like a more logical place for the bugtool plugins.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-vswitchd in the openvswitch-switch package is tightly coupled to its
database schema. During development, it's possible to change the schema
without changing the Open vSwitch version number, which makes it possible
for the openvswitch-switch and openvswitch-common packages to get out of
sync: openvswitch-switch requires the same version of openvswitch-common,
but if the version number doesn't get updated that has no effect.
Actually putting the schema and ovs-vswitchd (its primary user) in the
same package prevents them from getting out-of-sync. This commit also
moves ovsdb-tool because that program often works directly with OVSDB
schemas and so there's not much point having it around without a schema to
work with.
Originally I intended this as just a cleanup, but as a side effect it also
installs some files from the install tree in debian/tmp instead of from
_debian. This should avoid a reported problem in which ovs-bugtool was
being created in the source directory instead of the build directory (I
still don't see why this happened).
Reported-by: Sébastien RICCIO <sr@swisscenter.com>
Tested-by: Sébastien RICCIO <sr@swisscenter.com>
Acked-by: Simon Horman <horms@verge.net.au>
CC: Simon Horman <horms@verge.net.au>
All of the xen-bugtool plugins that OVS has previously installed only under
XenServer are equally useful with Debian and other distributions, so
this commit installs and uses them everywhere.
ovs-bugtool is no longer Debian-specific, so install it everywhere. (On
XenServer, specifically, we do not install it, because there xen-bugtool
already exists.)
ovs-bugtool creates a tarball of useful information which people
can submit with bug reports. The source is copied from xen-bugtool
with the xen specific removed or changed.
Until now, the OVSDB IDL annotations have been glommed together with the
schema information in a single file, and then we've used ovsdb-idlc to
extract the schema from that file. This commit reverses the process:
the schema and the annotations are stored separately and then glommed
together as necessary at build time.
This new arrangement has a few advantages:
- We can now easily have multiple different sets of IDL annotations
for a single OVSDB schema. For example, some users may not need
access to columns that other users do.
- Bugs in ovsdb-idlc cannot screw up the underlying schema (as shown
by a recent commit).
This appears to work in that it creates the database on installation,
starts and stops the programs and loads and unloads the kernel modules at
the right times, but it has not been tested beyond that.
