aboutsummaryrefslogtreecommitdiffstats
path: root/main/openvswitch/readme.debian.patch
blob: e641e70914eed2aacae056718e6d268f17871c54 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
--- 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