Improvements : IPv6 / Secondary addresses / Arguments parsing like PR…

…#27 / Verbose mode to trace all iproute2 calls / etc.

README.md

@@ -24,9 +24,12 @@ Pipework uses cgroups and namespace and works with "plain" LXC containers
 * [DHCP](#dhcp)  
 * [Specify a custom MAC address](#custom_mac)  
 * [Virtual LAN (VLAN)](#vlan)  
+* [IPv6](#ipv6)
+* [Secondary addresses](#secondary)
 * [Support Open vSwitch](#openvswitch)  
 * [Support Infiniband](#infiniband)
 * [Cleanup](#cleanup)  
+* [Experimental](#experimental)  
 
 
 <a name="notes"/>
@@ -76,7 +79,7 @@ Let's create two containers, running the web tier and the database tier:
 
 Now, bring superpowers to the web tier:
 
-    pipework br1 $APACHE 192.168.1.1/24
+    pipework br1 $APACHE -a ip 192.168.1.1/24
 
 This will:
 
@@ -87,7 +90,7 @@ This will:
 
 Now (drum roll), let's do this:
 
-    pipework br1 $MYSQL 192.168.1.2/24
+    pipework br1 $MYSQL -a ip 192.168.1.2/24
 
 This will:
 
@@ -107,7 +110,7 @@ you gave to Pipework cannot be found, Pipework will try to resolve it
 with `docker inspect`. This makes it even simpler to use:
 
     docker run -name web1 -d apache
-    pipework br1 web1 192.168.12.23/24
+    pipework br1 web1 -a ip 192.168.12.23/24
 
 
 <a name="peeking_inside"/>
@@ -123,7 +126,7 @@ Voilà!
 ### Setting container internal interface ##
 By default pipework creates a new interface `eth1` inside the container. In case you want to change this interface name like `eth2`, e.g., to have more than one interface set by pipework, use:
 
-`pipework br1 -i eth2 ...`
+`pipework br1 web1 -i eth2 ...`
 
 **Note:**: for infiniband IPoIB interfaces, the default interface name is `ib0` and not `eth1`.
 
@@ -135,7 +138,7 @@ tool; so you can append a subnet size using traditional CIDR notation.
 
 I.e.:
 
-    pipework br1 $CONTAINERID 192.168.4.25/20
+    pipework br1 $CONTAINERID -a ip 192.168.4.25/20
 
 Don't forget that all containers should use the same subnet size;
 pipework is not clever enough to use your specified subnet size for
@@ -155,7 +158,7 @@ you want the container to use a specific outbound IP address.
 This can be automated by Pipework, by adding the gateway address
 after the IP address and subnet mask:
 
-    pipework br1 $CONTAINERID 192.168.4.25/20@192.168.4.1
+    pipework br1 $CONTAINERID -a ip 192.168.4.25/20@192.168.4.1
 
 
 <a name="route_internal"/>
@@ -164,7 +167,7 @@ after the IP address and subnet mask:
 If you add more than one internal interface, or perform specific use-cases, you may want to add other routes than the default one. 
 This could be performed by adding network and masks after the gateway (comma-separated)
 
-    pipework br1 $CONTAINERID 192.168.4.25/20@192.168.4.1 192.168.5.0/25,192.168.6.0/24
+    pipework br1 $CONTAINERID -a ip 192.168.4.25/20@192.168.4.1 -r 192.168.5.0/25,192.168.6.0/24
 
 Please note that the last added internal interface will take the default route
 
@@ -175,8 +178,8 @@ Please note that the last added internal interface will take the default route
 Let's pretend that you want to run two Hipache instances, listening on real
 interfaces eth2 and eth3, using specific (public) IP addresses. Easy!
 
-    pipework eth2 $(docker run -d hipache /usr/sbin/hipache) 50.19.169.157/24
-    pipework eth3 $(docker run -d hipache /usr/sbin/hipache) 107.22.140.5/24
+    pipework eth2 $(docker run -d hipache /usr/sbin/hipache) -a ip 50.19.169.157/24
+    pipework eth3 $(docker run -d hipache /usr/sbin/hipache) -a ip 107.22.140.5/24
 
 Note that this will use `macvlan` subinterfaces, so you can actually put
 multiple containers on the same physical interface.
@@ -207,26 +210,14 @@ Then, you would start a container and assign it a macvlan interface
 the usual way:
 
     CID=$(docker run -d ...)
-    pipework eth0 $CID 10.1.1.234/24@10.1.1.254
+    pipework eth0 $CID -a ip 10.1.1.234/24@10.1.1.254
 
 
 <a name="wait_ready"/>
 ### Wait for the network to be ready
 
-Sometimes, you want the extra network interface to be up and running *before*
-starting your service. A dirty (and unreliable) solution would be to add
-a `sleep` command before starting your service; but that could break in
-"interesting" ways if the server happens to be a bit slower at one point.
-
-There is a better option: add the `pipework` script to your Docker image,
-and before starting the service, call `pipework --wait`. It will wait
-until the `eth1` interface is present and in `UP` operational state,
-then exit gracefully.
-
-If you need to wait on an interface other than eth1, pass the -i flag like
-this:
-
-    pipework --wait -i ib0
+Since `docker create` allow to instantiate the container without starting it, 
+there is no more reason for pipework to provide tooling to wait for the network. 
 
 <a name="no_ip"/>
 ### Add the interface without an IP address
@@ -236,7 +227,7 @@ container, you can use `0/0` as the IP address. The interface will
 be created, connected to the network, and assigned to the container,
 but without configuring an IP address:
 
-    pipework br1 $CONTAINERID 0/0
+    pipework br1 $CONTAINERID -a link
 
 
 <a name="dhcp"/>
@@ -245,7 +236,7 @@ but without configuring an IP address:
 You can use DHCP to obtain the IP address of the new interface. Just
 specify `dhcp` instead of an IP address; for instance:
 
-    pipework eth1 $CONTAINERID dhcp
+    pipework eth1 $CONTAINERID -a dhcp
 
 The value of $CONTAINERID will be provided to the DHCP client to use
 as the hostname in the DHCP request. Depending on the configuration of
@@ -279,15 +270,15 @@ If you need to specify the MAC address to be used (either by the `macvlan`
 subinterface, or the `veth` interface), no problem. Just add it as the
 command-line, as the last argument:
 
-    pipework eth0 $(docker run -d haproxy) 192.168.1.2/24 26:2e:71:98:60:8f
+    pipework eth0 $(docker run -d haproxy) -a ip 192.168.1.2/24 -m 26:2e:71:98:60:8f
 
 This can be useful if your network environment requires whitelisting
 your hardware addresses (some hosting providers do that), or if you want
 to obtain a specific address from your DHCP server. Also, some projects like
 [Orchestrator](https://github.com/cvlc/orchestrator) rely on static
 MAC-IPv6 bindings for DHCPv6:
 
-    pipework br0 $(docker run -d zerorpcworker) dhcp fa:de:b0:99:52:1c
+    pipework br0 $(docker run -d zerorpcworker) -a dhcp -m fa:de:b0:99:52:1c
 
 **Note:** if you generate your own MAC addresses, try remember those two
 simple rules:
@@ -302,6 +293,8 @@ be `2`, `6`, `a`, or `e`. You can check [Wikipedia](
 http://en.wikipedia.org/wiki/MAC_address) if you want even more details.
 
 **Note:**  Setting the MAC address of an IPoIB interface is not supported.
+
+
 <a name="vlan"/>
 ### Virtual LAN (VLAN)
 
@@ -315,7 +308,25 @@ bridges are currently not supported.
 The following will attach container zerorpcworker to the Open vSwitch bridge
 ovs0 and attach the container to VLAN ID 10.
 
-    pipework ovsbr0 $(docker run -d zerorpcworker) dhcp @10
+    pipework ovsbr0 $(docker run -d zerorpcworker) -a dhcp -V @10
+
+<a name="ipv6"/>
+### IPv6
+
+IPv6 adressing is also supported, using the same options : 
+
+	pipework eth0 eth0 $(docker run -d haproxy) -a ip 2001:db8::beef/64@2001:db8::1
+
+**Note:** Docker 1.5 feature
+
+<a name="secondary"/>
+### Secondary addresses
+
+You can attach secondary addresses the container, using the action `sec_ip` instead of `ip`
+
+	pipework eth0 eth0 $(docker run -d haproxy) -a sec_ip 192.168.1.2/24
+	pipework eth0 eth0 $(docker run -d haproxy) -a sec_ip 2001:db8::beef/64
+	pipework eth0 eth0 $(docker run -d haproxy) -a sec_ip 2001:db8::face/64
 
 <a name="openvswitch"/>
 ### Support Open vSwitch
@@ -324,7 +335,7 @@ If you want to attach a container to the Open vSwitch bridge, no problem.
 
     ovs-vsctl list-br
     ovsbr0
-    pipework ovsbr0 $(docker run -d mysql /usr/sbin/mysqld_safe) 192.168.1.2/24
+    pipework ovsbr0 $(docker run -d mysql /usr/sbin/mysqld_safe) -a ip 192.168.1.2/24
 
 If the ovs bridge doesn't exist, it will be automatically created
 
@@ -345,3 +356,12 @@ When a container is terminated (the last process of the net namespace exits),
 the network interfaces are garbage collected. The interface in the container
 is automatically destroyed, and the interface in the docker host (part of the
 bridge) is then destroyed as well.
+
+<a name="experimental"/>
+### Experimental
+
+TBD
+
+- Tunnel interfaces (GRE/IPIP/IP6_TUNNEL) 
+- Clean OVS bridge
+