The way ports are defined is confusing and should be redesigned.
@lloesche @BenWhitehead @lingmann @guenter
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.
@cmaloney I agree with your assessment of the global service ports but we have to continue supporting them for a while.
We have like 4 ways of doing this today, we need to fix it completely in v3, but otherwise out of scope.