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

Rethink ports API #670

Closed
ConnorDoyle opened this Issue Oct 2, 2014 · 3 comments

Comments

Projects
None yet
6 participants
@ConnorDoyle
Contributor

ConnorDoyle commented Oct 2, 2014

The way ports are defined is confusing and should be redesigned.

  1. Using our recommended HAProxy configuration, users have to think about an app's "local" ports, ports bound on the host, plus any NAT rules done by the containerizer.
  2. Ports may be defined via app.ports or app.container.docker.portMappings.
  3. The app.ports array is overloaded, with bearing on both "local" and host ports depending on the value of the app.requirePorts flag.

@lloesche @BenWhitehead @lingmann @guenter

@cmaloney

This comment has been minimized.

Show comment
Hide comment
@cmaloney

cmaloney Jan 20, 2015

Contributor

I like three classes of ports: Host ports, Container ports (Used for port mapping with docker primarily), and Service Ports (Used purely for haproxy-marathon-bridge type setups, deprecated hopefully).

Any port which is given as a zero should get replaced with some port from the offer the task ends up being launched with for host and service ports. Container ports are well-known / defined. If someone wants arbitraily defined container ports that is doable down the line, but I don't see a lot of value in them. The container lives in it's own space w.r.t. ports.

I'd personally like for Service Ports to leave the scope of marathon entirely (I like them either as mesos task labels or magic environment variables which a service discovery service can scoop up). If they need to stick around I'd say they are a separate array which specifies which host port should map to a service port.

Let me know if anything in there could use more clarification for what I'd like to see.

Contributor

cmaloney commented Jan 20, 2015

I like three classes of ports: Host ports, Container ports (Used for port mapping with docker primarily), and Service Ports (Used purely for haproxy-marathon-bridge type setups, deprecated hopefully).

Any port which is given as a zero should get replaced with some port from the offer the task ends up being launched with for host and service ports. Container ports are well-known / defined. If someone wants arbitraily defined container ports that is doable down the line, but I don't see a lot of value in them. The container lives in it's own space w.r.t. ports.

I'd personally like for Service Ports to leave the scope of marathon entirely (I like them either as mesos task labels or magic environment variables which a service discovery service can scoop up). If they need to stick around I'd say they are a separate array which specifies which host port should map to a service port.

Let me know if anything in there could use more clarification for what I'd like to see.

@air air added the usability label Mar 19, 2015

@kolloch

This comment has been minimized.

Show comment
Hide comment
@kolloch

kolloch Mar 24, 2015

Contributor

@cmaloney I agree with your assessment of the global service ports but we have to continue supporting them for a while.

Contributor

kolloch commented Mar 24, 2015

@cmaloney I agree with your assessment of the global service ports but we have to continue supporting them for a while.

@jasongilanfarr

This comment has been minimized.

Show comment
Hide comment
@jasongilanfarr

jasongilanfarr Nov 23, 2016

Contributor

We have like 4 ways of doing this today, we need to fix it completely in v3, but otherwise out of scope.

Contributor

jasongilanfarr commented Nov 23, 2016

We have like 4 ways of doing this today, we need to fix it completely in v3, but otherwise out of scope.

@mesosphere mesosphere locked and limited conversation to collaborators Mar 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.