Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assigning Address driver options #707

Merged
merged 1 commit into from
Dec 4, 2015
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion endpoint.go
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,8 @@ type endpoint struct {
anonymous bool
generic map[string]interface{}
joinLeaveDone chan struct{}
prefAddress net.IP
ipamOptions map[string]string
dbIndex uint64
dbExists bool
sync.Mutex
Expand Down Expand Up @@ -685,6 +687,14 @@ func EndpointOptionGeneric(generic map[string]interface{}) EndpointOption {
}
}

// CreateOptionIpam function returns an option setter for the ipam configuration for this endpoint
func CreateOptionIpam(prefAddress net.IP, ipamOptions map[string]string) EndpointOption {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of an InterfaceIpamConf structure so that it is easier to add more fields in future. But I cannot think of any other fields, besides the address and options.
Therefore I think It is better your way, less boilerplate code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea that makes sense. I have no problem changing it to that if others feel that it is needed now.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems that only one IP address can be passed. Would it be possible to have multiple per end point ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment. Currently we do not support that, but I think only few changes would make it possible.
Just curious about the use case, is this for IP aliasing ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aboch one of the use case is if you want to both have a VIP and a local address. This could be for anycast or implementing direct server return (https://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf). The second IP can be on the loopback or any interface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jc-m we do envision the support for properly defined Services and yes, we will have Virtual IPs, Load balancers and all the whole 9 yards. It is just that we are not there yet.

But you did bring up an important point that if you have a custom IPAM driver, then this should be a case of the IPAM driver handling it & libnetwork should not worry about that restriction. But still, even if we make the current PR handle multiple-ip, it stops short at the IPAM layer. The endpoint isnt assigned to multiple IPs when it ends up in the network Driver.
Wont you feel better to have a full e2e support for multiple IPs from the User to IPAM driver and ends up finally in the endpoint as seen by the network driver ?

Again, as @aboch suggested, we are fully supportive of multiple IP assignment for the endpoints for all the use-cases that you suggested. Just that we dont have it covered e2e.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mavenugo I obviously care about the e2e support. I see how supporting multiple IPs per endpoints can be a problem with the current model. Another way would have been to pass the preferred IPs in libnetwork.EndpointOptionGeneric , and this would have provided more flexibility. Some drivers could simply ignore them, others could use them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jc-m am glad that you brought up these points so that we can get it resolved soon. Will you mind opening an issue/proposal using which we can design it together to support multiple IPs e2e ?

My suggestion would be to let this PR work for a single IP which is supported e2e and work on a proposal to support multiple IPs end-to-end ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with getting this one go with 1 IP for now. We will provide a proposal for the multiple IPs building on this PR.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

created #798

return func(ep *endpoint) {
ep.prefAddress = prefAddress
ep.ipamOptions = ipamOptions
}
}

// CreateOptionExposedPorts function returns an option setter for the container exposed
// ports option to be passed to network.CreateEndpoint() method.
func CreateOptionExposedPorts(exposedPorts []types.TransportPort) EndpointOption {
Expand Down Expand Up @@ -799,7 +809,7 @@ func (ep *endpoint) assignAddressVersion(ipVer int, ipam ipamapi.Ipam) error {
if *address != nil {
prefIP = (*address).IP
}
addr, _, err := ipam.RequestAddress(d.PoolID, prefIP, nil)
addr, _, err := ipam.RequestAddress(d.PoolID, prefIP, ep.ipamOptions)
if err == nil {
ep.Lock()
*address = addr
Expand Down
2 changes: 2 additions & 0 deletions ipamapi/contract.go
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,8 @@ const (
DefaultIPAM = "default"
// PluginEndpointType represents the Endpoint Type used by Plugin system
PluginEndpointType = "IpamDriver"
// RequestAddressType represents the Address Type used when requesting an address
RequestAddressType = "RequestAddressType"
)

// Callback provides a Callback interface for registering an IPAM instance into LibNetwork
Expand Down
5 changes: 4 additions & 1 deletion network.go
Original file line number Diff line number Diff line change
Expand Up @@ -971,7 +971,10 @@ func (n *network) ipamAllocateVersion(ipVer int, ipam ipamapi.Ipam) error {
// irrespective of whether ipam driver returned a gateway already.
// If none of the above is true, libnetwork will allocate one.
if cfg.Gateway != "" || d.Gateway == nil {
if d.Gateway, _, err = ipam.RequestAddress(d.PoolID, net.ParseIP(cfg.Gateway), nil); err != nil {
var gatewayOpts = map[string]string{
ipamapi.RequestAddressType: netlabel.Gateway,
}
if d.Gateway, _, err = ipam.RequestAddress(d.PoolID, net.ParseIP(cfg.Gateway), gatewayOpts); err != nil {
return types.InternalErrorf("failed to allocate gateway (%v): %v", cfg.Gateway, err)
}
}
Expand Down