Great work guys! Couple of related high level questions, mostly around
customization:
(1) I imagine some folks may not want to use an endpoint for this. For
example, they may want the master to consult an external quota database,
file, etc as it is a bit easier to guarantee convergence with this
The cleanup has been committed:
https://issues.apache.org/jira/browse/MESOS-2640.
Jake,
Is it still against ASF policy if these frameworks are moved under
github.com/mesos but we make it very clear we are not taking contributions
to these repos and they are read-only? People can still fork them
I should have it for you in a couple of hours.
On Tue, Jul 7, 2015 at 11:12 AM, Adam B (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/MESOS-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617110#comment-14617110
]
Adam
Having a kill action will work fine for our module. By the way, our policy
mechanism doesn't kill individual tasks by their IDs, but rather kills
some task(s) of frameworks (or roles) that currently use more resources
than they deserve - to free up a defined amount of cpu/mem/etc. Hence, the
Hm.. are you guys planning to start working on this?
We should revisit the design here:
https://docs.google.com/document/d/1CIoOnBLFiEvmhOe-h_s8M4m9Qa7BLETuj_dSNJW959U/edit
Specifically, after getting feedback from folks working on storage systems,
they seem to really want the safety of explicit
In case it wasn't obvious, rc1 did not pass the vote, due to a few build
and unit test issues.
Most of those fixes have been committed, so we will cut rc2 when the last
blocker is resolved.
This is your last chance to get any recently committed patches or resolved
issues into 0.23.0.
I am tracking
Hi Ben,
Yes, we do plan to work on this. Thanks a lot for raising the concern!
We will change the first task to update the design doc and revive the
discussion around this.
Cheers,
Artem.
On Tue, Jul 7, 2015 at 3:20 PM, Benjamin Mahler
benjamin.mah...@gmail.com wrote:
Hm.. are you guys
Adam,
Having an HTTP API to kill a task would help.
I'd also suggest considering a 'native' killTask C++ API that can be
called from within a resource allocation module (
https://issues.apache.org/jira/browse/MESOS-2160).
This is a more direct route, since the module runs inside the master
As a general rule, we should not include anything other than the fixes in an
RC, to avoid introducing further bugs in a never-ending cycle.
Please keep the cherry-picking strictly limited to a very narrow set (which I'm
sure you're already doing, but your email seemed to imply otherwise ;-)
Hey folks,
I would like to announce the existence of a few new macros that were added
recently. They are: *CHECK_NONE, CHECK_ERROR, *AWAIT_EXPECT_TRUE and
AWAIT_EXPECT_FALSE.
Please take advantage of these macros rather than spelling them out!
*CHECK_NONE(x);* rather than *CHECK(x.isNone());*
I think we should move away from the callback architecture in Allocator and
avoid introducing new callbacks. In order to implement things like
optimistic offers [1], we may need to generate and bookkeep resource offers
in an allocator. In this case, a cleaner and more general solution is to
keep a
11 matches
Mail list logo
