Request to be added to mesos contributors

[Tim Harper]

I've submitted and worked on this issue: 
https://issues.apache.org/jira/browse/MESOS-5824 


Per the instructions 
 I'd like to 
be added to the contributors list so I can assign myself to the issue.

Thanks

Tim

MESOS-5731 Add metric types to GetMetrics v1 api

[Tuan-Anh Hoang-Vu]

Hi all,

I've finished implementing and testing this issue
https://issues.apache.org/jira/browse/MESOS-5731 and would like to find a
shepherd for my patch.

Should I go ahead and submit the patch?

Following Vinod's suggestion, I've changed Response::GetMetrics in
master.proto and v1/master.proto from

  message GetMetrics {
repeated Metric metrics = 1;
  }

to

  message GetMetrics {
repeated Metric counters = 1;
repeated Metric gauges = 2;
repeated Metric timers = 3;
  }

[GitHub] mesos pull request #136: Add Jacob Janco to contributors and remove whitespa...

[jacobjanco]

GitHub user jacobjanco opened a pull request:

https://github.com/apache/mesos/pull/136

Add Jacob Janco to contributors and remove whitespace.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jacobjanco/mesos add-jjanco-contributors

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/136.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #136


commit 61c725997040cb9d3721859c9a90e1f57d3b5148
Author: Jacob Janco 
Date:   2016-07-08T21:11:42Z

Add Jacob Janco to contributors.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #133: Output disk resource source information.

[rukletsov]

Github user rukletsov commented on the issue:

https://github.com/apache/mesos/pull/133
  
Why would we want to back port such change?


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #133: Output disk resource source information.

[kaysoky]

Github user kaysoky commented on the issue:

https://github.com/apache/mesos/pull/133
  
The travis CI is broken/not-maintained, since we don't (usually) make any 
code changes via GitHub PRs.  See: 
http://mesos.apache.org/documentation/latest/submitting-a-patch/

Can you file a JIRA for this change?  We might have to consider backwards 
compatibility if the resources string changes.  And we'd like that discussion 
to take place in JIRA.


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #133: Output disk resource source information.

[timcharper]

Github user timcharper commented on the issue:

https://github.com/apache/mesos/pull/133
  
I ran the tests manually and they still pass


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #133: Output disk resource source information.

[timcharper]

Github user timcharper commented on the issue:

https://github.com/apache/mesos/pull/133
  
Not sure why the tests have failed, but @rukletsov - I've updated the PR; 
it doesn't seem like a good idea to put a `CHECK` call into a string formatter, 
so I didn't. Do you disagree?


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request #135: Added drexin to contributors.yaml.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/135


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request #135: Added drexin to contributors.yaml.

[drexin]

GitHub user drexin opened a pull request:

https://github.com/apache/mesos/pull/135

Added drexin to contributors.yaml.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/drexin/mesos patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/135.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #135


commit 588992473a7993d4459bfe161070cf44f77f83f6
Author: Dario Rexin 
Date:   2016-07-08T18:28:39Z

Added drexin to contributors.yaml.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Replicated Log] Enable Mesos to use etcd for replicated_log

[Joseph Wu]

Jay,

(1) Looks like we missed this when we modularized the
MasterDetector/Contender [1].  We need to expand on src/master/main.cpp a
bit.
Can you file a bug?  (cc: Kapil)  I can shepherd if Kapil doesn't have the
cycles.

(2) The bit of the replicated log which relies on ZK is a small portion
called the ZookeeperNetwork [2].  The job of this component is to watch the
ZK group for membership changes.  Log replication messages are broadcasted
to all members in this "network abstraction".
This is also a piece that needs to be modularized.  (Can you file another
bug? :)

(3) The replicated log is something stored locally on the master (i.e.
LevelDB).  The network abstraction has some similarity with the
MasterDetector, but those pieces are otherwise unrelated.
i.e. The MasterContender is the piece that decides the "coordinator" of the
replicated log.  But the replicated log uses it's own implementation of
Paxos after the coordinator is chosen.

[1] https://issues.apache.org/jira/browse/MESOS-4610
[2] https://github.com/apache/mesos/blob/master/src/log/network.hpp#L107

On Fri, Jul 8, 2016 at 9:25 AM, Avinash Sridharan 
wrote:

> +Jie
>
> I think replicated log uses ZK only for leader election. Hence, without ZK
> the quorum is hard-coded to 1.
>
> For (#2), trying to understand what you mean by replicated log being
> pluggable? You mean turning of replicated log on the Master for storing
> Registrar information?
>
> On Fri, Jul 8, 2016 at 2:26 AM, Jay JN Guo  wrote:
>
> >
> >
> > Hi,
> >
> > We are working on a Mesos module to substitute Zookeeper with Etcd.
> > Contender and detector are done through modulerized interfaces, however,
> > replicated_log is still coupled with ZK. Here are my questions:
> >
> > #1 What's the difference between replicated_log with/without ZK? Without
> > flag --zk, Log is constructed with hardcoded quorum of 1. Does it assume
> > master to be running in non-HA mode? Otherwise, we observed that znodes
> are
> > created in ZK to store log_replica information, does it help Paxos
> > coordination in some way?
> > #2 We hope to make replicated_log pluggable. Some code change need to
> > happen in Mesos upstream (interface modulerization, extra flags, etc). So
> > we wonder if someone could shepherd them? Also, it would be great if we
> > could get some help on better understanding replicated_log internals.
> > #3 Is there a plan to use replicated_log to do master contend/detect
> > instead of ZK? If yes, what's the status?
> >
> > Your help and suggestions are highly appreciated!!
> >
> > Thanks,
> > /Jay
> >
>
>
>
> --
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245
>

Accepted: Updated Invitation: Community Meeting @ Thu Jul 14 11pm - Fri Jul 15, 2016 12am (CEST) (Apache Mesos)

[Deepak Vij (A)]

BEGIN:VCALENDAR
METHOD:REPLY
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;CN=Deepak Vij (A):MAILTO:deepak@huawei.com
SUMMARY;LANGUAGE=en-US:Accepted: Updated Invitation: Community Meeting @ Th
 u Jul 14 11pm - Fri Jul 15\, 2016 12am (CEST) (Apache Mesos)
DTSTART;TZID=Pacific Standard Time:20160714T14
DTEND;TZID=Pacific Standard Time:20160714T15
UID:vavklkdmf4hlonjarsofg8l...@google.com
RECURRENCE-ID;TZID=Pacific Standard Time:20160714T00
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20160708T163957Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:3
LOCATION;LANGUAGE=en-US:
X-MICROSOFT-CDO-APPT-SEQUENCE:3
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR

Re: MESOS-4694

[Dario Rexin]

Hi Alex,

thanks for your input. We originally thought about that, too, but the problem 
is, that every time resources are allocated to a framework, this method will be 
called:

void DRFSorter::add(const SlaveID& slaveId, const Resources& resources)

It will add the passed resources to the total resources of the sorter and 
therefore invalidate the whole sorting (i.e. set dirty=true). So we would still 
have to actually sort the frameworks almost every time. In fact, frameworks are 
already kept sorted as long as possible, it’s just not possible to keep them 
sorted for very long because of the call to said function ;).

--
 Dario

> On Jul 8, 2016, at 6:50 AM, Alex Rukletsov  wrote:
> 
> I was not involved into conversations around this issue, so maybe you have
> discussed this already (in this case, is the outcome of the discussion is
> documented somewhere?).
> 
> Though the patch seems good to me, it assumes that frameworks SUPPRESS when
> they don't need offers. This is not always the case. Since now we have a
> real world use case with ~6k frameworks, the "right thing to do" seems to
> maintain a heap of roles and frameworks in the role and avoid sorting.
> 
> On Thu, Jul 7, 2016 at 7:20 PM, Dario Rexin  wrote:
> 
>> A bit more context:
>> 
>> We have a very high number of frameworks on our clusters. In some cases
>> ~6k. The biggest problem is the sort method, which has a complexity of O(n
>> log n) and is called n*m times, where n = number of agents and m = number
>> of roles. So in total we have a complexity of O(n^3 log n). I think
>> reducing n is the most promising optimization here. We have been running
>> this patch in production for quite a while now and have seen huge
>> improvements in general allocation time and also in failover times.
>> 
>> Also, if we were to add a parameterized version of SUPPRESS, what problems
>> do you see with just differentiating between the two cases?
>> 
>> Thanks,
>> --
>>  Dario
>> 
>>> On Jul 7, 2016, at 8:40 AM, Dario Rexin  wrote:
>>> 
>>> Hi Joris,
>>> 
>>> I still don't really understand why we would parameterize SUPPRESS, to
>> me that sounds like a case for filters. The idea of SUPPRESS was to
>> completely stop getting offers.
>>> 
>>> Could you please explain why you think the patch is a hack? To me it
>> just seems logical to not sort frameworks that don't need to be considered
>> in the allocator.
>>> 
>>> Thanks,
>>> Dario
>>> 
 On 07.07.2016, at 7:38 AM, Joris Van Remoortere 
>> wrote:
 
 The reason that SUPPRESS doesn't just deactivate is because the intent
>> was
 to be able to parameterize this call. At that point the change wouldn't
 work without turning this in to 2 cases.
 
 I have asked to look at what a parameterized suppress would like and
 understand the performance impact of that before we do this.
 Have we reached consensus that there's no way to implement a generic
 parameterized suppress that is performant?
 
 There are some refactorings that we had discussed with James, Jacob, and
 Ian that seem like lower hanging fruit. After those are made it might be
 worth reconsidering whether we need to do this hack.
 
 
 
 —
 *Joris Van Remoortere*
 Mesosphere
 
> On Thu, Jul 7, 2016 at 10:15 AM, Guangya Liu 
>> wrote:
> 
> Hi Ben and Dario,
> 
> The reason that we have "SUPPRESS" call is as following:
> 1) Act as the complement to the current REVIVE call.
> 2) The HTTP API do not have an API to "Deactivate" a framework, we
>> want to
> use "SUPPRESS", "DECLINE" and "DECLINE_INVERSE_OFFERS" to implement the
> call for "DeactivateFrameworkMessage".
> 
> You can also refer to https://issues.apache.org/jira/browse/MESOS-3037
>> for
> detail.
> 
> So I think that Dario's patch is good, we should remove the framework
> clients when "SUPPRESS" and add the framework client back when
>> "REVIVE". to
> ignore those frameworks from sorter.
> 
> @Viond, any comments for this?
> 
> @Ben, for your concern of the benchmark test result is not easy to
> understand, I have filed a JIRA ticket here
> https://issues.apache.org/jira/browse/MESOS-5800 to trace.
> 
> Thanks,
> 
> Guangya
> 
> 
> 
>> On Thu, Jul 7, 2016 at 6:01 AM, Dario Rexin  wrote:
>> 
>> Hi Vinod,
>> 
>> thanks for your reply. The reason it’s so much faster is because the
>> sorting is a lot faster with fewer frameworks. Looping shouldn’t make
>> a
>> huge difference, as it used to just skip over the deactivated
>> frameworks.
>> 
>> I don’t know what effects deactivating the framework in the master
>> would
>> have. The framework is still active and listening for events / sending
>> calls. Could you please elaborate?
>> 
>> 

Re: [Replicated Log] Enable Mesos to use etcd for replicated_log

[Avinash Sridharan]

+Jie

I think replicated log uses ZK only for leader election. Hence, without ZK
the quorum is hard-coded to 1.

For (#2), trying to understand what you mean by replicated log being
pluggable? You mean turning of replicated log on the Master for storing
Registrar information?

On Fri, Jul 8, 2016 at 2:26 AM, Jay JN Guo  wrote:

>
>
> Hi,
>
> We are working on a Mesos module to substitute Zookeeper with Etcd.
> Contender and detector are done through modulerized interfaces, however,
> replicated_log is still coupled with ZK. Here are my questions:
>
> #1 What's the difference between replicated_log with/without ZK? Without
> flag --zk, Log is constructed with hardcoded quorum of 1. Does it assume
> master to be running in non-HA mode? Otherwise, we observed that znodes are
> created in ZK to store log_replica information, does it help Paxos
> coordination in some way?
> #2 We hope to make replicated_log pluggable. Some code change need to
> happen in Mesos upstream (interface modulerization, extra flags, etc). So
> we wonder if someone could shepherd them? Also, it would be great if we
> could get some help on better understanding replicated_log internals.
> #3 Is there a plan to use replicated_log to do master contend/detect
> instead of ZK? If yes, what's the status?
>
> Your help and suggestions are highly appreciated!!
>
> Thanks,
> /Jay
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Updated Invitation: Community Meeting @ Thu Jul 14 11pm - Fri Jul 15, 2016 12am (CEST) (Apache Mesos)

[mcypark]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20160714T14
DTEND;TZID=America/Los_Angeles:20160714T15
DTSTAMP:20160707T205946Z
ORGANIZER;CN=Apache Mesos:mailto:2hecvndc0mnaqlir34cqnfvtak@group.calendar.
 google.com
UID:vavklkdmf4hlonjarsofg8l...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@mesos.apache.org;X-NUM-GUESTS=0:mailto:dev@mesos.apache.org
RECURRENCE-ID;TZID=America/Los_Angeles:20160714T15
CREATED:20151120T072745Z
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
 =VIEW=dmF2a2xrZG1mNGhsb25qYXJzb2ZnOGxrMWNfMjAxNjA3MTRUMjIwMDAwWiBkZXZAb
 WVzb3MuYXBhY2hlLm9yZw=NTIjMmhlY3ZuZGMwbW5hcWxpcjM0Y3FuZnZ0YWtAZ3JvdXAuY
 2FsZW5kYXIuZ29vZ2xlLmNvbWE3MGEzYjk1OTM1NTYzMzhlOGQxODY5NjUyYTFkYWUwMmNiNjg5
 YWU=Europe/Berlin=en.
LAST-MODIFIED:20160707T205945Z
LOCATION:
SEQUENCE:3
STATUS:CONFIRMED
SUMMARY:Community Meeting
TRANSP:OPAQUE
ATTACH;FILENAME=Mesos Developer Community Sync;FMTTYPE=application/vnd.goog
 le-apps.document:https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7CO
 JDwKh9RDjxaTA0S7lzwDA/edit?usp=drive_web
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:dev@mesos.apache.org
TRIGGER:-P1D
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[GitHub] mesos pull request #134: Add Snap plugin to tools list

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/134


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #134: Add Snap plugin to tools list

[rji]

Github user rji commented on the issue:

https://github.com/apache/mesos/pull/134
  
From the mailing list and new community Slack, I've seen a bot handling 
GitHub PRs, so hopefully this is ok. Otherwise I'll open up a patch on 
Reviewboard.


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request #134: Add Snap plugin to tools list

[rji]

GitHub user rji opened a pull request:

https://github.com/apache/mesos/pull/134

Add Snap plugin to tools list

Add the newly-released Mesos plugin for Intel's 
[Snap](https://github.com/intelsdi-x/snap) telemetry framework to the tools 
documentation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rji/mesos add-snap-plugin-to-docs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/134.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #134


commit 52d694801d939fdf368614879d239088b2b5d741
Author: Roger Ignazio 
Date:   2016-07-08T15:47:17Z

(docs) add snap plugin to tools list




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: MESOS-4694

[Alex Rukletsov]

I was not involved into conversations around this issue, so maybe you have
discussed this already (in this case, is the outcome of the discussion is
documented somewhere?).

Though the patch seems good to me, it assumes that frameworks SUPPRESS when
they don't need offers. This is not always the case. Since now we have a
real world use case with ~6k frameworks, the "right thing to do" seems to
maintain a heap of roles and frameworks in the role and avoid sorting.

On Thu, Jul 7, 2016 at 7:20 PM, Dario Rexin  wrote:

> A bit more context:
>
> We have a very high number of frameworks on our clusters. In some cases
> ~6k. The biggest problem is the sort method, which has a complexity of O(n
> log n) and is called n*m times, where n = number of agents and m = number
> of roles. So in total we have a complexity of O(n^3 log n). I think
> reducing n is the most promising optimization here. We have been running
> this patch in production for quite a while now and have seen huge
> improvements in general allocation time and also in failover times.
>
> Also, if we were to add a parameterized version of SUPPRESS, what problems
> do you see with just differentiating between the two cases?
>
> Thanks,
> --
>  Dario
>
> > On Jul 7, 2016, at 8:40 AM, Dario Rexin  wrote:
> >
> > Hi Joris,
> >
> > I still don't really understand why we would parameterize SUPPRESS, to
> me that sounds like a case for filters. The idea of SUPPRESS was to
> completely stop getting offers.
> >
> > Could you please explain why you think the patch is a hack? To me it
> just seems logical to not sort frameworks that don't need to be considered
> in the allocator.
> >
> > Thanks,
> > Dario
> >
> >> On 07.07.2016, at 7:38 AM, Joris Van Remoortere 
> wrote:
> >>
> >> The reason that SUPPRESS doesn't just deactivate is because the intent
> was
> >> to be able to parameterize this call. At that point the change wouldn't
> >> work without turning this in to 2 cases.
> >>
> >> I have asked to look at what a parameterized suppress would like and
> >> understand the performance impact of that before we do this.
> >> Have we reached consensus that there's no way to implement a generic
> >> parameterized suppress that is performant?
> >>
> >> There are some refactorings that we had discussed with James, Jacob, and
> >> Ian that seem like lower hanging fruit. After those are made it might be
> >> worth reconsidering whether we need to do this hack.
> >>
> >>
> >>
> >> —
> >> *Joris Van Remoortere*
> >> Mesosphere
> >>
> >>> On Thu, Jul 7, 2016 at 10:15 AM, Guangya Liu 
> wrote:
> >>>
> >>> Hi Ben and Dario,
> >>>
> >>> The reason that we have "SUPPRESS" call is as following:
> >>> 1) Act as the complement to the current REVIVE call.
> >>> 2) The HTTP API do not have an API to "Deactivate" a framework, we
> want to
> >>> use "SUPPRESS", "DECLINE" and "DECLINE_INVERSE_OFFERS" to implement the
> >>> call for "DeactivateFrameworkMessage".
> >>>
> >>> You can also refer to https://issues.apache.org/jira/browse/MESOS-3037
> for
> >>> detail.
> >>>
> >>> So I think that Dario's patch is good, we should remove the framework
> >>> clients when "SUPPRESS" and add the framework client back when
> "REVIVE". to
> >>> ignore those frameworks from sorter.
> >>>
> >>> @Viond, any comments for this?
> >>>
> >>> @Ben, for your concern of the benchmark test result is not easy to
> >>> understand, I have filed a JIRA ticket here
> >>> https://issues.apache.org/jira/browse/MESOS-5800 to trace.
> >>>
> >>> Thanks,
> >>>
> >>> Guangya
> >>>
> >>>
> >>>
>  On Thu, Jul 7, 2016 at 6:01 AM, Dario Rexin  wrote:
> 
>  Hi Vinod,
> 
>  thanks for your reply. The reason it’s so much faster is because the
>  sorting is a lot faster with fewer frameworks. Looping shouldn’t make
> a
>  huge difference, as it used to just skip over the deactivated
> frameworks.
> 
>  I don’t know what effects deactivating the framework in the master
> would
>  have. The framework is still active and listening for events / sending
>  calls. Could you please elaborate?
> 
>  Thanks,
>  --
>   Dario
> 
>  On Jul 6, 2016, at 2:56 PM, Benjamin Mahler 
> wrote:
> 
>  +implementer and shepherd of SUPPRESS
> 
>  Is there any reason we didn't already just "deactivate" frameworks
> that
>  were suppressing offers? That seems to be the natural implementation,
>  performance aside, because the meaning of "deactivated" is: not being
> >>> sent
>  any offers. The patch you posted seems to only take this half-way:
> >>> suppress
>  = deactivation in the allocator, but not in the master.
> 
>  Also, Dario it's a bit hard to interpret these numbers without reading
> >>> the
>  benchmark code. My interpretation of these numbers is that this change
>  makes the allocation loop complete more quickly 

[GitHub] mesos pull request #133: Output disk resource source information.

[rukletsov]

Github user rukletsov commented on a diff in the pull request:

https://github.com/apache/mesos/pull/133#discussion_r70072622
  
--- Diff: src/common/resources.cpp ---
@@ -1475,6 +1475,20 @@ ostream& operator<<(ostream& stream, const Volume& 
volume)
   return stream;
 }
 
+ostream& operator<<(ostream& stream, const Resource::DiskInfo::Source& 
source)
+{
+  stream << source.type();
+
+  if (source.has_path()) {
--- End diff --

It looks like the common pattern is to switch on the type. Could you please 
follow this pattern? You can convert `has_*()` into `CHECK`s.


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request #132: Add self to contributors

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/132


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos issue #62: Update README.md

[rukletsov]

Github user rukletsov commented on the issue:

https://github.com/apache/mesos/pull/62
  
Could you please update your RR with suggestions from Adam? 


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[Replicated Log] Enable Mesos to use etcd for replicated_log

[Jay JN Guo]

Hi,

We are working on a Mesos module to substitute Zookeeper with Etcd.
Contender and detector are done through modulerized interfaces, however,
replicated_log is still coupled with ZK. Here are my questions:

#1 What's the difference between replicated_log with/without ZK? Without
flag --zk, Log is constructed with hardcoded quorum of 1. Does it assume
master to be running in non-HA mode? Otherwise, we observed that znodes are
created in ZK to store log_replica information, does it help Paxos
coordination in some way?
#2 We hope to make replicated_log pluggable. Some code change need to
happen in Mesos upstream (interface modulerization, extra flags, etc). So
we wonder if someone could shepherd them? Also, it would be great if we
could get some help on better understanding replicated_log internals.
#3 Is there a plan to use replicated_log to do master contend/detect
instead of ZK? If yes, what's the status?

Your help and suggestions are highly appreciated!!

Thanks,
/Jay

[GitHub] mesos pull request #133: Output disk resource source information.

[timcharper]

GitHub user timcharper opened a pull request:

https://github.com/apache/mesos/pull/133

Output disk resource source information.

This information is obscured when formatted via `stringify`, leading to 
confusing error messages such as:

```
Task uses more resources
cpus(*):4; mem(*):4096; ports(*):[31000-31000]; disk(kafka, 
kafka)[kafka_0:data]:960679
than available
cpus(*):32; mem(*):256819;  ports(*):[31000-32000]; disk(kafka, 
kafka)[kafka_0:data]:960679;   disk(*):240169;
```

(above was formatted and aligned for clarity)

The validation error here is actually complaining that the disk requested 
didn't have any source information (and therefore defaulted to a root volume), 
but the available persistent volume was a mount source.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vivint-smarthome/mesos 0.28.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/133.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #133


commit bdb533c5de2b44f9dab873b16c3c7e28d53bcca4
Author: Tim Harper 
Date:   2016-07-08T09:00:32Z

Output disk resource source information.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---