mirror of
https://gitlab.alpinelinux.org/alpine/aports.git
synced 2025-08-05 21:37:15 +02:00
120 lines
5.0 KiB
Diff
120 lines
5.0 KiB
Diff
--- a/debian/openvswitch-switch.README.Debian
|
|
--- b/debian/openvswitch-switch.README.Debian
|
|
@@ -1,48 +1,8 @@
|
|
-README.Debian for openvswitch-switch
|
|
----------------------------------
|
|
-
|
|
-To use the Linux kernel-based switch implementation, you will need an
|
|
-Open vSwitch kernel module. There are multiple ways to obtain one.
|
|
-In order of increasing manual effort, these are:
|
|
-
|
|
- * Use a Linux kernel 3.3 or later, which has an integrated Open
|
|
- vSwitch kernel module.
|
|
-
|
|
- The upstream Linux kernel module lacks a few features that
|
|
- are in the third-party module. For details, please see the
|
|
- FAQ, "What features are not available in the Open vSwitch
|
|
- kernel datapath that ships as part of the upstream Linux
|
|
- kernel?".
|
|
-
|
|
- * Install the "openvswitch-datapath-dkms" Debian package that
|
|
- you built earlier. This should automatically build and
|
|
- install the Open vSwitch kernel module for your running
|
|
- kernel.
|
|
-
|
|
- This option requires that you have a compiler and toolchain
|
|
- installed on the machine where you run Open vSwitch, which
|
|
- may be unacceptable in some production server environments.
|
|
-
|
|
- * Install the "openvswitch-datapath-source" Debian package, use
|
|
- "module-assistant" to build a Debian package of the Open
|
|
- vSwitch kernel module for your kernel, and then install that
|
|
- Debian package.
|
|
-
|
|
- You can install the kernel module Debian packages that you
|
|
- build this way on the same machine where you built it or on
|
|
- another machine or machines, which means that you don't
|
|
- necessarily have to have any build infrastructure on the
|
|
- machines where you use the kernel module.
|
|
-
|
|
- /usr/share/doc/openvswitch-datapath-source/README.Debian has
|
|
- details on the build process.
|
|
-
|
|
- * Build and install the kernel module by hand.
|
|
-
|
|
-
|
|
-Debian network scripts integration
|
|
-----------------------------------
|
|
-This package lets a user to optionally configure Open vSwitch bridges
|
|
+README.Alpine for Openvswitch
|
|
+-----------------------------
|
|
+network scripts integration
|
|
+-----------------------------
|
|
+This package enables a user to optionally configure Open vSwitch bridges
|
|
and ports from /etc/network/interfaces. Please refer to the interfaces(5)
|
|
manpage for more details regarding /etc/network/interfaces.
|
|
|
|
@@ -202,43 +162,29 @@
|
|
|
|
ex 8: Create and destroy bridges.
|
|
|
|
-ifup --allow=ovs $list_of_bridges
|
|
-ifdown --allow=ovs $list_of_bridges
|
|
+ifup $list_of_bridges
|
|
+ifdown $list_of_bridges
|
|
|
|
-Notes on dependencies:
|
|
----------------------
|
|
+Notes on LXC integration:
|
|
+-------------------------
|
|
|
|
-openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
|
|
-This creates some startup dependency issues.
|
|
+To prevent containers failing to start after hard reboots create:
|
|
+-----------------------------------------------------------------
|
|
|
|
-* Since openvswitch utilities are placed in /usr and /usr can be mounted
|
|
-through NFS, openvswitch has to start after it. But if a user uses openvswitch
|
|
-for all his networking needs and hence to mount NFS, there will be a deadlock.
|
|
-So, if /usr is mounted through NFS and openvswitch is used for all networking,
|
|
-the administrator should figure out a way to mount NFS before starting OVS.
|
|
-One way to do this is in initramfs.
|
|
+/etc/lxc/ovsup:
|
|
|
|
-* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
|
|
-script that depends on openvswitch but starts before it, needs to be changed
|
|
-to depend on openvswitch-switch too.
|
|
+#!/bin/sh
|
|
+ovs-vsctl --if-exists del-port $5
|
|
+-----------------------------------------------------------------
|
|
|
|
-* Ideally, an admin should not add openvswitch bridges in the 'auto'
|
|
-section of the 'interfaces' file (i.e., if "br0" is a OVS bridge, you should
|
|
-not have a line "auto br0"). This is because, when ifupdown starts
|
|
-working on bridges listed in 'auto', openvswitch has not yet started.
|
|
+/etc/lxc/ovsdown:
|
|
|
|
-But, if the admin wants to go down this route and adds openvswitch bridges
|
|
-in the 'auto' section, openvswitch-switch will forcefully be started when
|
|
-ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
|
|
-has already been mounted and that a remote $syslog (if used) is ready to
|
|
-receive openvswitch logs.
|
|
+#!/bin/sh
|
|
|
|
-* With systemd, adding openvswitch bridges in the 'auto' section of the
|
|
-'interfaces' file can cause race conditions (i.e., if "br0" is a OVS bridge,
|
|
-you should not have a line "auto br0"). Debian systems have added a
|
|
-systemd ifup@.service file. This file will call ifdown and ifup on interfaces
|
|
-in "auto" section automatically when the interfaces disappear and appear
|
|
-respectively. This will cause race conditions if you delete and add the same
|
|
-bridges using tools like "ovs-vsctl" or "ovs-dpctl". This is also a problem
|
|
-when you upgrade your openvswitch kernel module using commands like
|
|
-'force-reload-kmod'.
|
|
+ovs-vsctl --if-exists del-port veth.$LXC_NAME
|
|
+-----------------------------------------------------------------
|
|
+
|
|
+& add to the container config file:
|
|
+
|
|
+lxc.hook.pre-start = /etc/lxc/ovsup
|
|
+lxc.hook.post-stop = /etc/lxc/ovsdown
|