[
https://issues.apache.org/jira/browse/AURORA-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505912#comment-14505912
]
Bill Farner commented on AURORA-1289:
-------------------------------------
*note* the mention of static ports in that doc assumes dedicated machines are
used, so the machine is already specially-handled.
I agree that ideally these ports would be handled as a resource, and static
ports muddies this. For this reason Aurora by default prevents use of static
ports on shared machines _in the Announcer configuration_. I emphasize the
last part since ultimately we currently have no means to prevent a process from
binding to a port that Aurora did not allocate to it. This is a hole, but we
currently lack built-in controls in Mesos to do more than that.
Ultimately, the guidance we give is to use dynamically-allocated ports whenever
possible, but as you may have seen in AURORA-1212 we have uncovered use cases
that may demand this. Supporting statically-assigned ports brings up
additional issues of Aurora being out of the loop for what ports a user has
privilege to bind, as well as what ports are in use by system services.
> Preclude co-scheduling of multiple tasks with the same static port
> ------------------------------------------------------------------
>
> Key: AURORA-1289
> URL: https://issues.apache.org/jira/browse/AURORA-1289
> Project: Aurora
> Issue Type: Story
> Reporter: zane silver
> Assignee: Bill Farner
>
> The current documentation states that,
> "Static ports should be used cautiously as Aurora does nothing to prevent two
> tasks with the same static port allocations from being co-scheduled".
> http://aurora.apache.org/documentation/latest/configuration-reference/#announcer-objects
> Is there a benefit to being able to co-schedule two (or more) tasks with the
> same static port number to the same machine? It would seem that this is a
> bug. The proper functionality should treat static ports as a resource: once
> the port is acquired by a task, it will not be offered to any other task
> until the port resource is released. Therefore, no two tasks with the same
> port can be co-scheduled to the same machine.
> The current implementation requires that clients using the Aurora scheduler
> have global knowledge of all static port allocations. This is clearly
> impossible for a large and scalable system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
