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

Add service virtual IP to sandbox's loopback address #1877

Merged
merged 1 commit into from Aug 9, 2017

Conversation

Projects
None yet
3 participants
@fcrisciani
Member

fcrisciani commented Aug 1, 2017

Refreshed the PR: #1585
Addressed comments suggesting to remove the IPAlias logic not anymore used

Signed-off-by: Flavio Crisciani flavio.crisciani@docker.com

@sanimej

This comment has been minimized.

Show comment
Hide comment
@sanimej

sanimej Aug 2, 2017

Contributor

Change LGTM.

This will change the VIP assignment behavior that we have had since 1.12.x and can impact apps that make assumptions about the alias IP. Generally such assumptions are bad practices and its unlikely there are many such apps. So this looks ok to me. @mavenugo wdyt ?

Contributor

sanimej commented Aug 2, 2017

Change LGTM.

This will change the VIP assignment behavior that we have had since 1.12.x and can impact apps that make assumptions about the alias IP. Generally such assumptions are bad practices and its unlikely there are many such apps. So this looks ok to me. @mavenugo wdyt ?

@fcrisciani

This comment has been minimized.

Show comment
Hide comment
@fcrisciani
Member

fcrisciani commented Aug 3, 2017

@mavenugo PTAL

if len(ep.virtualIP) != 0 {
vipAlias := &net.IPNet{IP: ep.virtualIP, Mask: net.CIDRMask(32, 32)}
ifaceOptions = append(ifaceOptions, sb.osSbox.InterfaceOptions().IPAliases([]*net.IPNet{vipAlias}))
}

This comment has been minimized.

@mavenugo

mavenugo Aug 3, 2017

Contributor

@fcrisciani am yet to go over the details of this. But it seems like we are missing calling the method to add the vip to the loopback interface ?

@mavenugo

mavenugo Aug 3, 2017

Contributor

@fcrisciani am yet to go over the details of this. But it seems like we are missing calling the method to add the vip to the loopback interface ?

This comment has been minimized.

@fcrisciani

fcrisciani Aug 3, 2017

Member

yep looks like it

@fcrisciani

fcrisciani Aug 3, 2017

Member

yep looks like it

This comment has been minimized.

@mavenugo

mavenugo Aug 9, 2017

Contributor

With the loopback interface replacing the endpoint interface to host the virtual-ip, there is no need for restoreOslSandbox to restore the states, since there is no state to be restored in OSL Sandbox :-)
The change is good to go as is.

@mavenugo

mavenugo Aug 9, 2017

Contributor

With the loopback interface replacing the endpoint interface to host the virtual-ip, there is no need for restoreOslSandbox to restore the states, since there is no state to be restored in OSL Sandbox :-)
The change is good to go as is.

@fcrisciani

This comment has been minimized.

Show comment
Hide comment
@fcrisciani

fcrisciani Aug 3, 2017

Member

Updated the commit but I would like to discuss the case here with you @mavenugo before the merge

Member

fcrisciani commented Aug 3, 2017

Updated the commit but I would like to discuss the case here with you @mavenugo before the merge

Add service virtual IP to sandbox's loopback address
Refreshed the PR: #1585
Addressed comments suggesting to remove the IPAlias logic not anymore used

Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>

@mavenugo mavenugo merged commit 24bb72a into docker:master Aug 9, 2017

2 checks passed

ci/circleci Your tests passed on CircleCI!
Details
dco-signed All commits are signed

@fcrisciani fcrisciani deleted the fcrisciani:viplo branch Aug 14, 2017

jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Dec 30, 2017

Only bind loopback addresses when binding to local
Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

jasontedor added a commit to elastic/elasticsearch that referenced this pull request Jan 2, 2018

Only bind loopback addresses when binding to local
* Only bind loopback addresses when binding to local

Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

Relates #28029

jasontedor added a commit to elastic/elasticsearch that referenced this pull request Jan 2, 2018

Only bind loopback addresses when binding to local
* Only bind loopback addresses when binding to local

Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

Relates #28029

jasontedor added a commit to elastic/elasticsearch that referenced this pull request Jan 2, 2018

Only bind loopback addresses when binding to local
* Only bind loopback addresses when binding to local

Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

Relates #28029

jasontedor added a commit to elastic/elasticsearch that referenced this pull request Jan 2, 2018

Only bind loopback addresses when binding to local
* Only bind loopback addresses when binding to local

Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

Relates #28029

jasontedor added a commit to elastic/elasticsearch that referenced this pull request Jan 2, 2018

Only bind loopback addresses when binding to local
* Only bind loopback addresses when binding to local

Today when binding to local (the default) we bind to any address that is
a loopback address, or any address on an interface that declares itself
as a loopback interface. Yet, not all addresses on loopback interfaces
are loopback addresses. This arises on macOS where there is a link-local
address assigned to the loopback interface (fe80::1%lo0) and in Docker
services where virtual IPs of the service are assigned to the loopback
interface (docker/libnetwork#1877). These situations cause problems:
 - because we do not handle the scope ID of a link-local address, we end
   up bound to an address for which publishing of that address does not
   allow that address to be reached (since we drop the scope)
 - the virtual IPs in the Docker situation are not loopback addresses,
   they are not link-local addresses, so we end up bound to interfaces
   that cause the bootstrap checks to be enforced even though the
   instance is only bound to local

We address this by only binding to actual loopback addresses, and skip
binding to any address on a loopback interface that is not a loopback
address. This lets us simplify some code where in the bootstrap checks
we were skipping link-local addresses, and in writing the ports file
where we had to skip link-local addresses because again the formatting
of them does not allow them to be connected to by another node (to be
clear, they could be connected to via the scope-qualified address, but
that information is not written out).

Relates #28029
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment