Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rethink ports API #670
The way ports are defined is confusing and should be redesigned.
referenced this issue
Oct 3, 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.