close
Skip to content

Use complete port configs when plumbing mark rules#1432

Merged
mavenugo merged 2 commits into
moby:masterfrom
mrjana:lb
Sep 22, 2016
Merged

Use complete port configs when plumbing mark rules#1432
mavenugo merged 2 commits into
moby:masterfrom
mrjana:lb

Conversation

@mrjana

@mrjana mrjana commented Sep 7, 2016

Copy link
Copy Markdown
Contributor

Currently, a reference counting scheme is used to reference count all
individual port configs that need to be plumbed in the ingress to make
sure that in situations where a service with the same set of port
configs is getting added or removed doesn't accidentally remove the port
config plumbing if the add/remove notifications come out of order. This
same reference counting scheme is also used for plumbing the port-based
marking rules. But marking rules should not be plumbed based on that
because marks are always different for different instantiations of the
same service. So fixed the code to plumb port-based mark rules based on
the complete set of port configs, while plumbing pure port rules and
proxies based on a filter set of port configs based on the reference
count.

Signed-off-by: Jana Radhakrishnan mrjana@docker.com

Currently, a reference counting scheme is used to reference count all
individual port configs that need to be plumbed in the ingress to make
sure that in situations where a service with the same set of port
configs is getting added or removed doesn't accidentally remove the port
config plumbing if the add/remove notifications come out of order. This
same reference counting scheme is also used for plumbing the port-based
marking rules. But marking rules should not be plumbed based on that
because marks are always different for different instantiations of the
same service. So fixed the code to plumb port-based mark rules based on
the complete set of port configs, while plumbing pure port rules and
proxies based on a filter set of port configs based on the reference
count.

Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Comment thread service_linux.go
}

func writePortsToFile(ports []*PortConfig) (string, error) {
f, err := ioutil.TempFile("", "port_configs")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Are we removing these files somewhere, or are they just accumulating in the tmp directory ?
Can the file creation frequency be that high that we should worry about removing them ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We are not removing them but that has been the case forever since this code was there. We can fix it here though.

With port redirect in the ingress path happening before ipvs in the
ingess sandbox, there is a chance of 5-tuple collision in the ipvs
connection table for two entirely different services have different
PublishedPorts but the same TargetPort. To disambiguate the ipvs
connection table, delay the port redirect from PublishedPort to
TargetPort until after the loadbalancing has happened in ipvs. To be
specific, perform the redirect after the packet enters the real backend
container namespace.

Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Comment thread service_linux.go

ingressPortsFile = f.Name()
f.Close()
defer os.Remove(ingressPortsFile)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

👍

Comment thread service_linux.go
if err != nil {
return err
}
defer os.Remove(ingressPortsFile)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

👍

@aboch

aboch commented Sep 22, 2016

Copy link
Copy Markdown
Contributor

LGTM

1 similar comment
@mavenugo

Copy link
Copy Markdown
Contributor

LGTM

@mavenugo mavenugo merged commit f4de3a4 into moby:master Sep 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants