Rethink ports API #670

ConnorDoyle opened this Issue Oct 2, 2014 · 3 comments


None yet

6 participants


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

@ConnorDoyle ConnorDoyle added the cleanup label Oct 2, 2014
@ConnorDoyle ConnorDoyle added this to the 0.8.0 milestone Oct 2, 2014

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 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.

@kolloch kolloch modified the milestone: 0.9.0, 0.10.0, Backlog May 18, 2015

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

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