@benm/joris,
here's the user scenario in my mind:
1. master offers resources to the framework, e.g. 2 cpu
2. framework launch a task (2 cpu) and *mark the task/executors as
throttleable*
3. in ResourceEstimator, it should only consider the throttleable
task/executors:
- keep enough resources
Sorry, I didn't realize the summary of this ticket had changed since this
email was generated, and the plan is now to migrate the test to the new
scheduler library.
On Mon, Mar 21, 2016 at 11:21 PM, Benjamin Mahler
wrote:
> +joseph
>
> Have you seen this?
>
> On Tue, Mar 15, 2016 at 7:13 AM, Gre
+joseph
Have you seen this?
On Tue, Mar 15, 2016 at 7:13 AM, Greg Mann (JIRA) wrote:
> Greg Mann created MESOS-4948:
>
>
> Summary: MasterMaintenanceTest.InverseOffers is flaky
> Key: MESOS-4948
> URL: https://issue
+jie
Jie, have you seen this?
On Wed, Feb 10, 2016 at 7:46 AM, Greg Mann (JIRA) wrote:
> Greg Mann created MESOS-4635:
>
>
> Summary: CoordinatorTest.AppendDiscarded is flaky
> Key: MESOS-4635
> URL: https://issues.
Folks,
Our JIRA volume is very high and I'm finding that important bugs and flaky
tests are getting lost in the noise. When filing a bug or a flaky test
ticket as a dev in the project, it's critical to 'git blame' the code to
determine who is responsible for it, in order to notify them of the issu
I'm finding these are getting lost in the noise, it would be great when
filing test issue tickets to 'git blame' the code and figure out who to
notify to fix the test. Could you do that here?
On Fri, Mar 18, 2016 at 3:55 PM, Neil Conway (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/b
Hi folks,
I wanted to surface the following ticket to our attention:
https://issues.apache.org/jira/browse/MESOS-4997
The issue is that when enum fields are deserialized, unknown enum values
are _stripped_. This means that if an enum field is 'required' and a new
value is added, old clients canno
Some of my thinking here:
1) The ThrottleInfo may need to belong to "Resources" but not limited to
"RevocableInfo". The cpus resources can be throttled even if it is not
revocable resources.
2) There need to be a flag to indicate if the resources is Scavenge-able or
Best effort, I did not have
+jie, Tomasz
Looks like this new test needs a filter. Can one of you follow up with a
fix?
On Mon, Mar 21, 2016 at 12:51 PM, Neil Conway (JIRA)
wrote:
> Neil Conway created MESOS-4993:
> --
>
> Summary: FetcherTest.ExtractZipFile assumes `unzip` is
>
Yes it has existed for a long time but has only been discovered recently.
The way this was discovered was that garbage collection of user sandboxes
fails, which can result in the disk eventually filling up. This occurs when
there are special files in the sandbox (e.g. socket file).
IMO it's a cri
A single branch for a release seems brittle because it assumes that RC tag
N shares the same lineage as RC tag N-1. This is mostly true, but not
always. The branching approach that would mirror how I've put together
releases would be to have a branch for each RC. The RC N branch is usually
on top o
Yeah that's definitely a question I've been asking myself, and we synced on
that with Niklas during the last meeting. The thought currently is that we
should choose a better name than ThrottleInfo. ThrottleInfo seems to carry
too strong of an implication about what the resources will experience.
Ra
+Yan
On Mon, Mar 21, 2016 at 10:28 AM, Anurag Singh <
anurag.prakash.si...@gmail.com> wrote:
> Joseph's suggestion is that since Ben Hindman may not have enough time to
> shepherd this issue, we should seek another one. Would anyone here be able
> to shepherd https://issues.apache.org/jira/browse
Joseph's suggestion is that since Ben Hindman may not have enough time to
shepherd this issue, we should seek another one. Would anyone here be able
to shepherd https://issues.apache.org/jira/browse/MESOS-4610?
On Tue, Mar 15, 2016 at 1:13 PM, Anurag Singh <
anurag.prakash.si...@gmail.com> wrote:
> On Mar 18, 2016, at 10:22 AM, Michael Park wrote:
>
> Hi James,
>
> Someone would need to propose to auto-format everything with clang-format
> and convince the community
> that while clang-format will never be perfect, it generates a systematic,
> sane and just as readable codebase.
> If we
No, sorry--we'll collect the votes on Friday.
Thanks,
David
On Sun, Mar 20, 2016 at 9:01 PM Darren Haas wrote:
> Hi David,
>
> We could always start the ranking using shuf. :) Is it possible to show
> the current votes during the ranking?
>
> Thanks,
> Darren
>
>
>
>
> Sent from my iPhone
> On
@klaus:
I think @connor's question is whether we are absolutely sure we never want
to support throttle-able but non-revocable resources.
It's clear from the protos that this is not supported, the question is
whether we are sure that is what we want. If so, can you elaborate as to
*why* we would nev
The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes into
release candidates.
I'm all for using branches in the repository to put together the release
candidates, as well as have committers consider their bug fixes for some N
number of backport (future LTS) releases.
As Kevin an
18 matches
Mail list logo
