Github user asfgit closed the pull request at:
https://github.com/apache/mesos/pull/194
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabl
GitHub user nlsun opened a pull request:
https://github.com/apache/mesos/pull/194
Change `Accept-Type` to `Accept` in operator api docs.
The `Accept` header is the one that is actually used.
You can merge this pull request into a Git repository by running:
$ git pull https://gi
Whatever the solution will be, it will be great to stay consistent. It
looks like updating configuration during agent lifetime is a typical task,
hence having a "standard approach" would be great. Agent Whitelist and ACLS
come to my mind.
On 8 Dec 2016 7:24 am, "Avinash Sridharan" wrote:
> Valid
I'm fine with prohibiting non-unique IDs, but why do you plan to keep the
most recent in case of a conflict? I'd expect any duplicate (that we can
find out) is rejected / killed / banned / unchurched.
On 9 Dec 2016 8:13 pm, "Joris Van Remoortere" wrote:
> Hey Neil,
>
> I concur that using duplic
Granularity in the allocator is a single agent. Hence even though you set
quota for 0.0001 CPU, at least one agent is "blocked". This is probably the
reason why marathon is not getting offers. You can turn verbose master logs
and check allocator messages to confirm.
Alex.
On 10 Dec 2016 2:14 am,
