2015-05-06 16:57:38 -07:00
|
|
|
package remote
|
|
|
|
|
|
|
|
import (
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
"fmt"
|
|
|
|
"net"
|
2015-05-06 16:57:38 -07:00
|
|
|
|
2015-05-15 18:14:36 -07:00
|
|
|
log "github.com/Sirupsen/logrus"
|
|
|
|
"github.com/docker/docker/pkg/plugins"
|
2015-05-06 16:57:38 -07:00
|
|
|
"github.com/docker/libnetwork/driverapi"
|
|
|
|
"github.com/docker/libnetwork/types"
|
|
|
|
)
|
|
|
|
|
|
|
|
type driver struct {
|
2015-05-15 18:14:36 -07:00
|
|
|
endpoint *plugins.Client
|
|
|
|
networkType string
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
func newDriver(name string, client *plugins.Client) driverapi.Driver {
|
|
|
|
return &driver{networkType: name, endpoint: client}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Init makes sure a remote driver is registered when a network driver
|
|
|
|
// plugin is activated.
|
Make driver packages register themselves via DriverCallback
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-11 13:46:29 +01:00
|
|
|
func Init(dc driverapi.DriverCallback) error {
|
2015-05-15 18:14:36 -07:00
|
|
|
plugins.Handle(driverapi.NetworkPluginEndpointType, func(name string, client *plugins.Client) {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
if err := dc.RegisterDriver(name, newDriver(name, client)); err != nil {
|
|
|
|
log.Errorf("error registering driver for %s due to %v", name, err)
|
2015-05-15 18:14:36 -07:00
|
|
|
}
|
|
|
|
})
|
Make driver packages register themselves via DriverCallback
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-11 13:46:29 +01:00
|
|
|
return nil
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
// Config is not implemented for remote drivers, since it is assumed
|
|
|
|
// to be supplied to the remote process out-of-band (e.g., as command
|
|
|
|
// line arguments).
|
2015-05-06 16:57:38 -07:00
|
|
|
func (d *driver) Config(option map[string]interface{}) error {
|
2015-05-14 14:56:15 -07:00
|
|
|
return &driverapi.ErrNotImplemented{}
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
func (d *driver) call(methodName string, arg interface{}, retVal maybeError) error {
|
|
|
|
method := driverapi.NetworkPluginEndpointType + "." + methodName
|
|
|
|
err := d.endpoint.Call(method, arg, retVal)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if e := retVal.getError(); e != "" {
|
|
|
|
return fmt.Errorf("remote: %s", e)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (d *driver) CreateNetwork(id types.UUID, options map[string]interface{}) error {
|
|
|
|
create := &createNetworkRequest{
|
|
|
|
NetworkID: string(id),
|
|
|
|
Options: options,
|
|
|
|
}
|
|
|
|
return d.call("CreateNetwork", create, &createNetworkResponse{})
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (d *driver) DeleteNetwork(nid types.UUID) error {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
delete := &deleteNetworkRequest{NetworkID: string(nid)}
|
|
|
|
return d.call("DeleteNetwork", delete, &deleteNetworkResponse{})
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
2015-05-14 06:23:45 +00:00
|
|
|
func (d *driver) CreateEndpoint(nid, eid types.UUID, epInfo driverapi.EndpointInfo, epOptions map[string]interface{}) error {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
if epInfo == nil {
|
|
|
|
return fmt.Errorf("must not be called with nil EndpointInfo")
|
|
|
|
}
|
|
|
|
|
|
|
|
reqIfaces := make([]*endpointInterface, len(epInfo.Interfaces()))
|
|
|
|
for i, iface := range epInfo.Interfaces() {
|
|
|
|
addr4 := iface.Address()
|
|
|
|
addr6 := iface.AddressIPv6()
|
|
|
|
reqIfaces[i] = &endpointInterface{
|
|
|
|
ID: iface.ID(),
|
|
|
|
Address: addr4.String(),
|
|
|
|
AddressIPv6: addr6.String(),
|
|
|
|
MacAddress: iface.MacAddress().String(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
create := &createEndpointRequest{
|
|
|
|
NetworkID: string(nid),
|
|
|
|
EndpointID: string(eid),
|
|
|
|
Interfaces: reqIfaces,
|
|
|
|
Options: epOptions,
|
|
|
|
}
|
|
|
|
var res createEndpointResponse
|
|
|
|
if err := d.call("CreateEndpoint", create, &res); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
ifaces, err := res.parseInterfaces()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if len(reqIfaces) > 0 && len(ifaces) > 0 {
|
|
|
|
// We're not supposed to add interfaces if there already are
|
|
|
|
// some. Attempt to roll back
|
|
|
|
return errorWithRollback("driver attempted to add more interfaces", d.DeleteEndpoint(nid, eid))
|
|
|
|
}
|
|
|
|
for _, iface := range ifaces {
|
|
|
|
var addr4, addr6 net.IPNet
|
|
|
|
if iface.Address != nil {
|
|
|
|
addr4 = *(iface.Address)
|
|
|
|
}
|
|
|
|
if iface.AddressIPv6 != nil {
|
|
|
|
addr6 = *(iface.AddressIPv6)
|
|
|
|
}
|
|
|
|
if err := epInfo.AddInterface(iface.ID, iface.MacAddress, addr4, addr6); err != nil {
|
|
|
|
return errorWithRollback(fmt.Sprintf("failed to AddInterface %v: %s", iface, err), d.DeleteEndpoint(nid, eid))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func errorWithRollback(msg string, err error) error {
|
|
|
|
rollback := "rolled back"
|
|
|
|
if err != nil {
|
|
|
|
rollback = "failed to roll back: " + err.Error()
|
|
|
|
}
|
|
|
|
return fmt.Errorf("%s; %s", msg, rollback)
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (d *driver) DeleteEndpoint(nid, eid types.UUID) error {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
delete := &deleteEndpointRequest{
|
|
|
|
NetworkID: string(nid),
|
|
|
|
EndpointID: string(eid),
|
|
|
|
}
|
|
|
|
return d.call("DeleteEndpoint", delete, &deleteEndpointResponse{})
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
2015-05-14 06:23:45 +00:00
|
|
|
func (d *driver) EndpointOperInfo(nid, eid types.UUID) (map[string]interface{}, error) {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
info := &endpointInfoRequest{
|
|
|
|
NetworkID: string(nid),
|
|
|
|
EndpointID: string(eid),
|
|
|
|
}
|
|
|
|
var res endpointInfoResponse
|
|
|
|
if err := d.call("EndpointOperInfo", info, &res); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return res.Value, nil
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Join method is invoked when a Sandbox is attached to an endpoint.
|
2015-05-14 06:23:45 +00:00
|
|
|
func (d *driver) Join(nid, eid types.UUID, sboxKey string, jinfo driverapi.JoinInfo, options map[string]interface{}) error {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
join := &joinRequest{
|
|
|
|
NetworkID: string(nid),
|
|
|
|
EndpointID: string(eid),
|
|
|
|
SandboxKey: sboxKey,
|
|
|
|
Options: options,
|
|
|
|
}
|
|
|
|
var (
|
|
|
|
res joinResponse
|
|
|
|
err error
|
|
|
|
)
|
|
|
|
if err = d.call("Join", join, &res); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Expect each interface ID given by CreateEndpoint to have an
|
|
|
|
// entry at that index in the names supplied here. In other words,
|
|
|
|
// if you supply 0..n interfaces with IDs 0..n above, you should
|
|
|
|
// supply the names in the same order.
|
|
|
|
ifaceNames := res.InterfaceNames
|
|
|
|
for _, iface := range jinfo.InterfaceNames() {
|
|
|
|
i := iface.ID()
|
|
|
|
if i >= len(ifaceNames) || i < 0 {
|
|
|
|
return fmt.Errorf("no correlating interface %d in supplied interface names", i)
|
|
|
|
}
|
|
|
|
supplied := ifaceNames[i]
|
2015-06-01 15:35:57 -07:00
|
|
|
if err := iface.SetNames(supplied.SrcName, supplied.DstPrefix); err != nil {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
return errorWithRollback(fmt.Sprintf("failed to set interface name: %s", err), d.Leave(nid, eid))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var addr net.IP
|
|
|
|
if res.Gateway != "" {
|
|
|
|
if addr = net.ParseIP(res.Gateway); addr == nil {
|
|
|
|
return fmt.Errorf(`unable to parse Gateway "%s"`, res.Gateway)
|
|
|
|
}
|
|
|
|
if jinfo.SetGateway(addr) != nil {
|
|
|
|
return errorWithRollback(fmt.Sprintf("failed to set gateway: %v", addr), d.Leave(nid, eid))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if res.GatewayIPv6 != "" {
|
|
|
|
if addr = net.ParseIP(res.GatewayIPv6); addr == nil {
|
|
|
|
return fmt.Errorf(`unable to parse GatewayIPv6 "%s"`, res.GatewayIPv6)
|
|
|
|
}
|
|
|
|
if jinfo.SetGatewayIPv6(addr) != nil {
|
|
|
|
return errorWithRollback(fmt.Sprintf("failed to set gateway IPv6: %v", addr), d.Leave(nid, eid))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if jinfo.SetHostsPath(res.HostsPath) != nil {
|
|
|
|
return errorWithRollback(fmt.Sprintf("failed to set hosts path: %s", res.HostsPath), d.Leave(nid, eid))
|
|
|
|
}
|
|
|
|
if jinfo.SetResolvConfPath(res.ResolvConfPath) != nil {
|
|
|
|
return errorWithRollback(fmt.Sprintf("failed to set resolv.conf path: %s", res.ResolvConfPath), d.Leave(nid, eid))
|
|
|
|
}
|
|
|
|
return nil
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Leave method is invoked when a Sandbox detaches from an endpoint.
|
2015-05-14 06:23:45 +00:00
|
|
|
func (d *driver) Leave(nid, eid types.UUID) error {
|
Remote driver implementation
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-16 17:27:21 +01:00
|
|
|
leave := &leaveRequest{
|
|
|
|
NetworkID: string(nid),
|
|
|
|
EndpointID: string(eid),
|
|
|
|
}
|
|
|
|
return d.call("Leave", leave, &leaveResponse{})
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func (d *driver) Type() string {
|
2015-05-15 18:14:36 -07:00
|
|
|
return d.networkType
|
2015-05-06 16:57:38 -07:00
|
|
|
}
|