-
Notifications
You must be signed in to change notification settings - Fork 427
Deploy Marathon without Docker container, bump Marathon to 1.6.352 (MARATHON-8180) #1829
Conversation
I'm very much in favor of this change. I think other services in the universe download the Mesos native client library; is there any case where we can't depend on this being installed and available on an agent? |
I'm not sure about changing the default memory limits, though. Why are the current values insufficient, and for which size of cluster? |
Further, we need to confirm if this configuration will apply cgroup limitations for at least CPU |
@timcharper There's no change in CPUs allocation, 2 CPUs should be enough as a default (even for larger clusters). Marathon's heap allocation is quite greedy (have a look at screenshots from MARATHON-8180). Increasing the default memory limit is no big deal. Currently it means that instead of restarting every 12 hours Marathon would be killed every 16 hours due to memory limit. If you're strongly against this change I can revert that. Marathon's memory allocation doesn't seem to be related directly to cluster size. It's more likely connected to number of heath checks or number of event subscribers. Kafka or Elastic (from DC/OS Catalog) are deployed the same way. Moreover it reduces differences between |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though I certainly agree with the premise this is not an option. Mesos team war very rigorous about frameworks, in general, not relying on the host for Mesos libraries. This is the main reason why we have the image (this plus other dependencies that we have).
@zen-dog I'm sorry, I forgot to include |
We had an internal discussion about it a while ago. it boiled down to the fact that marathon is an open-source project and our
Indeed, then we could do the switch. It would actually simplify our build pipeline quite a bit. |
@zen-dog I agree, This PR about simplifying Marathon testing pipeline, allowing easier debugging and avoiding Marathon on Marathon crashes. Issues you mention are important, but out of scope of this PR. |
While debugging Marathon's memory usage, I've run into several issues that should be addressed by this PR:
MESOS_HTTP
health check (Use MESOS_HTTP rather than HTTP for health checks #1667)Marathon binary is fetched from the same deployment URI as for DC/OS "root" Marathon (
dcos-marathon
service).Benefits:
Diff: