community/openvswitch: move from main

Closes !154

1 files changed, 123 insertions, 0 deletions

diff --git a/community/openvswitch/readme.debian.patch b/community/openvswitch/readme.debian.patch
new file mode 100644
index 0000000000..af89a0d355
--- /dev/null
+++ b/community/openvswitch/readme.debian.patch
@@ -0,0 +1,123 @@
+--- 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 LXC integration:
++-------------------------
++
++To prevent containers failing to start after hard reboots create:
++-----------------------------------------------------------------
++
++/etc/lxc/ovsup:
++
++#!/bin/sh
++ovs-vsctl --if-exists del-port $5
++-----------------------------------------------------------------
++
++/etc/lxc/ovsdown:
++
++#!/bin/sh
+ 
+-Notes on dependencies:
+----------------------
++ovs-vsctl --if-exists del-port veth.$LXC_NAME
++-----------------------------------------------------------------
+ 
+-openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
+-This creates some startup dependency issues.
++& add to the container config file:
+ 
+-* 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.
+-
+-* 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.
+-
+-* 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.
+-
+-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.
+-
+-* 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'.
++lxc.hook.pre-start = /etc/lxc/ovsup
++lxc.hook.post-stop = /etc/lxc/ovsdown