- Believe we need sudo to create netns
- Use syscall instead of relying on ip netns
- Add sudo to .travis.yml
- Needs more -E
- Revert Godeps GoVersion to 1.4.2
- in travis, test command is run with all necessary env vars
- Loopback plugin only works on 'lo' interface
- Update README, add loopback plugin config
- note script dependency on jq
Signed-off-by: Gabe Rosenhouse <grosenhouse@pivotal.io>
Allow users to tune net network parameters such as somaxconn.
With this patch, users can add a new network configuration:
> {
> "name": "mytuning",
> "type": "tuning",
> "sysctl": {
> "net.core.somaxconn": "500"
> }
> }
The value /proc/sys/net/core/somaxconn will be set to 500 in the network
namespace but will remain unchanged on the host.
Only sysctl parameters that belong to the network subsystem can be
modified.
Related to: https://github.com/coreos/rkt/pull/2140
Allow users to tune net network parameters such as somaxconn.
With this patch, users can add a new network configuration:
> {
> "name": "mytuning",
> "type": "tuning",
> "sysctl": {
> "net.core.somaxconn": "500"
> }
> }
The value /proc/sys/net/core/somaxconn will be set to 500 in the network
namespace but will remain unchanged on the host.
Only sysctl parameters that belong to the network subsystem can be
modified.
Related to: https://github.com/coreos/rkt/pull/2140
Eugene is no longer with CoreOS or actively involved with CNI, so remove
him from the current list of maintainers. He'll be gladly welcomed back
if he decides to rejoin the project.
appc/cni#76 added a "dns" field in the result JSON. But before this
patch, the plugins had no way of knowing which name server to return.
There could be two ways of knowing which name server to return:
1. add it as an extra argument ("CNI_ARGS")
2. add it in the network configuration as a convenience (received via
stdin)
I chose the second way because it is easier. In the case of rkt, it
means the user could just add the DNS name servers in
/etc/rkt/net.d/mynetwork.conf.
appc/cni#76 added a "dns" field in the result JSON. But before this
patch, the plugins had no way of knowing which name server to return.
There could be two ways of knowing which name server to return:
1. add it as an extra argument ("CNI_ARGS")
2. add it in the network configuration as a convenience (received via
stdin)
I chose the second way because it is easier. In the case of rkt, it
means the user could just add the DNS name servers in
/etc/rkt/net.d/mynetwork.conf.
appc/cni#76 added a "dns" field in the result JSON. But before this
patch, the plugins had no way of knowing which name server to return.
There could be two ways of knowing which name server to return:
1. add it as an extra argument ("CNI_ARGS")
2. add it in the network configuration as a convenience (received via
stdin)
I chose the second way because it is easier. In the case of rkt, it
means the user could just add the DNS name servers in
/etc/rkt/net.d/mynetwork.conf.
