community/openvswitch: move from main

Closes !154

1 files changed, 0 insertions, 123 deletions

diff --git a/main/openvswitch/readme.debian.patch b/main/openvswitch/readme.debian.patch
deleted file mode 100644
index af89a0d355..0000000000
--- a/main/openvswitch/readme.debian.patch
+++ /dev/null
@@ -1,123 +0,0 @@
---- 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