Re: mesos-master resource offer details

[haosdent]

Hi, Haripriya.

>1. I am trying to see the details of the resource offer made by the mesos
master. I can see in the logs that there are 5 resource offers made but I
am not sure where to get the details of the resource offers - the cpu,
memory etc.

You could print offer details in your framework Scheduler#resourceOffers
methods. These offer message also could find from mesos log.

>2. How can I list the number of slaves registered with the master and the
details of the slaves on the command line( apart from seeing it in the UI)?

We have some endpoints(state.json and state-summary) in master and slave to
expose these informations, you could got this from

```
curl -s "http://localhost:5050/master/state-summary; |jq .slaves
```


On Tue, Sep 1, 2015 at 6:47 AM, Haripriya Ayyalasomayajula <
aharipriy...@gmail.com> wrote:

> Hello,
>
> I'm having trouble with some basic details:
>
> 1. I am trying to see the details of the resource offer made by the mesos
> master. I can see in the logs that there are 5 resource offers made but I
> am not sure where to get the details of the resource offers - the cpu,
> memory etc.
>
> 2. How can I list the number of slaves registered with the master and the
> details of the slaves on the command line( apart from seeing it in the UI)?
>
> Thanks for the help.
>
> --
> Regards,
> Haripriya Ayyalasomayajula
>
>


-- 
Best Regards,
Haosdent Huang

Recommended way to discover current master

[Philip Weaver]

My framework knows the list of zookeeper hosts and the list of mesos master
hosts.

I can think of a few ways for the framework to figure out which host is the
current master. What would be the best? Should I check in zookeeper
directly? Does the mesos library expose an interface to discover the master
from zookeeper or otherwise? Should I just try each possible master until
one responds?

Apologies if this is already well documented, but I wasn't able to find it.
Thanks!

- Philip

Re: Recommended way to discover current master

[James Peach]

> On Aug 31, 2015, at 10:25 AM, Philip Weaver  wrote:
> 
> My framework knows the list of zookeeper hosts and the list of mesos master 
> hosts.
> 
> I can think of a few ways for the framework to figure out which host is the 
> current master. What would be the best? Should I check in zookeeper directly? 
> Does the mesos library expose an interface to discover the master from 
> zookeeper or otherwise? Should I just try each possible master until one 
> responds?

If you want to do it the HTTP way, just hit the /master/redirect enndpoint on 
any master that you can reach.

> 
> Apologies if this is already well documented, but I wasn't able to find it. 
> Thanks!
> 
> - Philip
> 

Re: Recommended way to discover current master

[Marco Massenzio]

The easiest way is via accessing directly Zookeeper - as you don't need to
know a priori the list of Masters; if you do, however, hitting any one of
them will redirect (302) to the current Leader.

If you would like to see an example of how to retrieve that info from ZK, I
have written about it here[0].
Finally, we're planning to make all this available via the Mesos Commons[1]
library (currently, there is a PR[2] waiting to be be merged).


[0]
http://codetrips.com/2015/08/16/apache-mesos-leader-master-discovery-using-zookeeper-part-2/
[1] https://github.com/mesos/commons
[2] https://github.com/mesos/commons/pull/2/files

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com *

On Mon, Aug 31, 2015 at 10:25 AM, Philip Weaver 
wrote:

> My framework knows the list of zookeeper hosts and the list of mesos
> master hosts.
>
> I can think of a few ways for the framework to figure out which host is
> the current master. What would be the best? Should I check in zookeeper
> directly? Does the mesos library expose an interface to discover the master
> from zookeeper or otherwise? Should I just try each possible master until
> one responds?
>
> Apologies if this is already well documented, but I wasn't able to find
> it. Thanks!
>
> - Philip
>
>

Re: Recommended way to discover current master

[Philip Weaver]

Excellent, thank you both!

On Mon, Aug 31, 2015 at 10:39 AM, Marco Massenzio 
wrote:

> The easiest way is via accessing directly Zookeeper - as you don't need to
> know a priori the list of Masters; if you do, however, hitting any one of
> them will redirect (302) to the current Leader.
>
> If you would like to see an example of how to retrieve that info from ZK,
> I have written about it here[0].
> Finally, we're planning to make all this available via the Mesos
> Commons[1] library (currently, there is a PR[2] waiting to be be merged).
>
>
> [0]
> http://codetrips.com/2015/08/16/apache-mesos-leader-master-discovery-using-zookeeper-part-2/
> [1] https://github.com/mesos/commons
> [2] https://github.com/mesos/commons/pull/2/files
>
> *Marco Massenzio*
>
> *Distributed Systems Engineerhttp://codetrips.com *
>
> On Mon, Aug 31, 2015 at 10:25 AM, Philip Weaver 
> wrote:
>
>> My framework knows the list of zookeeper hosts and the list of mesos
>> master hosts.
>>
>> I can think of a few ways for the framework to figure out which host is
>> the current master. What would be the best? Should I check in zookeeper
>> directly? Does the mesos library expose an interface to discover the master
>> from zookeeper or otherwise? Should I just try each possible master until
>> one responds?
>>
>> Apologies if this is already well documented, but I wasn't able to find
>> it. Thanks!
>>
>> - Philip
>>
>>
>

Re: Recommended way to discover current master

[Connor Doyle]

It's also worth noting the existence of the `mesos-resolve` binary, which can 
turn a canonical Mesos ZK string into the leading master location.
--
Connor


> On Aug 31, 2015, at 10:39, Marco Massenzio  wrote:
> 
> The easiest way is via accessing directly Zookeeper - as you don't need to 
> know a priori the list of Masters; if you do, however, hitting any one of 
> them will redirect (302) to the current Leader.
> 
> If you would like to see an example of how to retrieve that info from ZK, I 
> have written about it here[0].
> Finally, we're planning to make all this available via the Mesos Commons[1] 
> library (currently, there is a PR[2] waiting to be be merged).
> 
> 
> [0] 
> http://codetrips.com/2015/08/16/apache-mesos-leader-master-discovery-using-zookeeper-part-2/
> [1] https://github.com/mesos/commons
> [2] https://github.com/mesos/commons/pull/2/files
> 
> Marco Massenzio
> Distributed Systems Engineer
> http://codetrips.com
> 
> On Mon, Aug 31, 2015 at 10:25 AM, Philip Weaver  
> wrote:
> My framework knows the list of zookeeper hosts and the list of mesos master 
> hosts.
> 
> I can think of a few ways for the framework to figure out which host is the 
> current master. What would be the best? Should I check in zookeeper directly? 
> Does the mesos library expose an interface to discover the master from 
> zookeeper or otherwise? Should I just try each possible master until one 
> responds?
> 
> Apologies if this is already well documented, but I wasn't able to find it. 
> Thanks!
> 
> - Philip
> 
> 

Re: Mesos-master complains about quorum being a duplicate flag on CoreOS

[Marco Massenzio]

Thanks for following up, glad we figured it out.

IMO the current behavior (and the error message) are non-intuitive and I've
filed a Jira[0] to address that.

[0] https://issues.apache.org/jira/browse/MESOS-3340

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com *

On Mon, Aug 31, 2015 at 1:59 AM, F21  wrote:

> Ah, that makes sense!
>
> I have the environment variable MESOS_QUORUM exported and it was
> conflicting with the --quorum passed to the command line.
>
> Removing the MESOS_QUORUM environment variable fixed it.
>
>
> On 31/08/2015 5:36 PM, Marco Massenzio wrote:
>
> Command line flags are parsed using stout/flags.hpp[0] and the FlagsBase
> class is derived in mesos::internal::master::Flags (see
> src/master/flags.hpp[1]).
>
> I am not sure why you are seeing that behavior on CoreOS, but I'd be
> curious to know what happens if you omit the --quorum when you start
> master: it should usually fail and complain that it's a required flag (when
> used in conjunction with --zk).  If it works, it will emit in the logs
> (towards the very beginning) all the values of the flags: what does it say
> about --quorum?
>
> Completely random question: I assume you don't already have in the
> environment a MESOS_QUORUM variable exported?
>
> If the issue persists in a "clean" OS install and a recent build, it's
> definitely a bug: it'd be great if you could please file a ticket at
> http://issues.apache.org/jira (feel free to assign to me).
>
> Thanks!
>
> [0]
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp
> [1]
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/master/flags.hpp
>
> *Marco Massenzio*
>
> *Distributed Systems Engineer http://codetrips.com *
>
> On Sun, Aug 30, 2015 at 8:21 PM, F21  wrote:
>
>> I've gotten the mesos binaries compiled and packaged and deployed them
>> onto a CoreOS instance.
>>
>>
>> When I run the master, it complains that the quorum flag is duplicated:
>>
>> $ ./mesos-master --zk=zk://192.168.1.4/mesos --quorum=1
>> --hostname=192.168.1.4 --ip=192.168.1.4
>> Duplicate flag 'quorum' on command line
>> ...
>>
>> However, if I try and run mesos-master on Ubuntu 15.04 64-bit (where the
>> binaries were built), it seems to work properly:
>>
>> $ ./mesos-master --zk=zk://192.168.1.4/mesos --quorum=1
>> --hostname=192.168.1.4 --ip=192.168.1.4
>>
>> I0830 18:31:20.983999 2830 main.cpp:181] Build: 2015-08-30 10:11:54 by
>> I0830 18:31:20.984246 2830 main.cpp:183] Version: 0.23.0
>> I0830 18:31:20.984694 2830 main.cpp:204] Using 'HierarchicalDRF'
>> allocator --work_dir needed for replicated log based registry
>>
>> How are the command line flags parsed in mesos? What causes this strange
>> behavior on CoreOS?
>>
>>
>>
>
>

mesos-slave crashing with CHECK_SOME

[Scott Rankin]

Hi all,

We are running Mesos 0.22.1 on CentOS 6 and are hitting some frequent 
mesos-slave crashes when we try to upgrade our Marathon applications.  The 
crash happens when Marathon deploys a new version of an application and stops a 
running task.  The error in the Mesos logs is:

tag=mesos-slave[12858]:  F0831 09:37:29.838184 12898 slave.cpp:3354] 
CHECK_SOME(os::touch(path)): Failed to open file: No such file or directory
tag=mesos-slave[12858]:  *** Check failure stack trace: ***
tag=mesos-slave[12858]:  @   0x36a46765cd  (unknown)
tag=mesos-slave[12858]:  @   0x36a467a5e7  (unknown)
tag=mesos-slave[12858]:  @   0x36a4678469  (unknown)
tag=mesos-slave[12858]:  @   0x36a467876d  (unknown)
tag=mesos-slave[12858]:  @   0x36a3fc5696  (unknown)
tag=mesos-slave[12858]:  @   0x36a421855a  (unknown)
tag=mesos-slave[12858]:  @   0x36a421c0a9  (unknown)
tag=mesos-slave[12858]:  @   0x36a42510ff  (unknown)
tag=mesos-slave[12858]:  @   0x36a4618b83  (unknown)
tag=mesos-slave[12858]:  @   0x36a461978c  (unknown)
tag=mesos-slave[12858]:  @   0x3699407a51  (unknown)
tag=mesos-slave[12858]:  @   0x36990e89ad  (unknown)
tag=init:  mesos-slave main process (12858) killed by ABRT signal

It appears in the log immediately after the Docker container stops.  The 
mesos-slave process respawns, but in doing so kills all of the running Docker 
containers on that slave.  It then appears that the mesos-slave process 
terminates a second time, then comes up successfully.  The logs from this 
process are below.

This has been reported by at least one other Marathon user here:  
https://groups.google.com/forum/#!topic/marathon-framework/oKXhfQUcoMQ

Any advice on how to go about troubleshooting this would be most appreciated!

Thanks,
Scott



tag=mesos-slave[17756]:  W0831 09:37:42.474733 17783 slave.cpp:2568] Could not 
find the executor for status update TASK_FINISHED (UUID: 
8583e68d-99f0-4a89-a0fd-af5012a1b35d) for task 
app_pingfederate-console.37953216-4ffe-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:42.861536 17781 slave.cpp:2557] Ignoring 
status update TASK_FINISHED (UUID: 7251ad5f-7850-471f-9976-b7162e183d0e) for 
task app_legacy.74d76339-4c08-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:42.962225 17779 slave.cpp:2557] Ignoring 
status update TASK_FINISHED (UUID: b6c60f4b-3e7d-46f9-ad54-630f5be1241f) for 
task app_pingfederate-engine.aa4f77a1-46ce-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:43.363952 17780 slave.cpp:2557] Ignoring 
status update TASK_FAILED (UUID: 0d44ee67-f9e3-48d7-b4e1-39d66babcd42) for task 
marathon-hipache-bridge.1461d8c2-411a-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:46.479511 17781 slave.cpp:2557] Ignoring 
status update TASK_FINISHED (UUID: f0cf57e3-3cbd-43f2-bbb2-55ad442a8abc) for 
task service_userservice.b4d14d32-45b9-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:52.476265 17779 
status_update_manager.cpp:472] Resending status update TASK_FINISHED (UUID: 
8583e68d-99f0-4a89-a0fd-af5012a1b35d) for task 
app_pingfederate-console.37953216-4ffe-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:52.476434 17779 slave.cpp:2731] Dropping 
status update TASK_FINISHED (UUID: 8583e68d-99f0-4a89-a0fd-af5012a1b35d) for 
task app_pingfederate-console.37953216-4ffe-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 sent by status update manager 
because the slave is in TERMINATING state
tag=mesos-slave[17756]:  W0831 09:37:54.727569 17782 slave.cpp:2557] Ignoring 
status update TASK_FAILED (UUID: c5e4092e-75cd-44c8-9ee5-efc53f304df3) for task 
service_tripbatchservice.6228c9d7-4a99-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  W0831 09:37:54.814648 17782 slave.cpp:2557] Ignoring 
status update TASK_FAILED (UUID: a681b752-9522-4acf-8c9f-c6530999d096) for task 
service_mapservice.18904037-411a-11e5-bd36-005056a00679 of framework 
20141209-011108-1378273290-5050-23221-0001 for terminating framework 
20141209-011108-1378273290-5050-23221-0001
tag=mesos-slave[17756]:  E0831 09:37:57.225787 17783 slave.cpp:3112] Container 
'f3da678a-e566-4179-b66a-084e055d32e4' for 

Re: [VOTE] Release Apache Mesos 0.24.0 (rc1)

[Vinod Kone]

Hi Dario,

Can you test with "curl --no-buffer" option? Looks like your stdout might
be line-buffered.

The reason we used record-io formatting is to be consistent in how we
stream protobuf and json encoded data.

On Fri, Aug 28, 2015 at 2:04 PM,  wrote:

> Anand,
>
> thanks for the explanation. I didn't think about the case when you have to
> split a message, now it makes sense.
>
> But the case I observed with curl is still weird. Even when splitting a
> message, it should still receive both parts almost at the same time. Do you
> have any idea why it could behave like this?
>
> On 28.08.2015, at 21:31, Anand Mazumdar  wrote:
>
> Dario,
>
> Most HTTP libraries/parsers ( including one that Mesos uses internally )
> provide a way to specify a default size of each chunk. If a Mesos Event is
> too big , it would get split into smaller chunks and vice-versa.
>
> -anand
>
> On Aug 28, 2015, at 11:51 AM, dario.re...@me.com wrote:
>
> Anand,
>
> in the example from my first mail you can see that curl prints the size of
> a message and then waits for the next message and only when it receives
> that message it will print the prior message plus the size of the next
> message, but not the actual message.
>
> What's the benefit of encoding multiple messages in a single chunk? You
> could simply create a single chunk per event.
>
> Cheers,
> Dario
>
> On 28.08.2015, at 19:43, Anand Mazumdar  wrote:
>
> Dario,
>
> Can you shed a bit more light on what you still find puzzling about the
> CURL behavior after my explanation ?
>
> PS: A single HTTP chunk can have 0 or more Mesos (Scheduler API) Events.
> So in your example, the first chunk had complete information about the
> first “event”, followed by partial information about the subsequent event
> from another chunk.
>
> As for the benefit of using RecordIO format here, how else do you think we
> could have de-marcated two events in the response ?
>
> -anand
>
>
> On Aug 28, 2015, at 10:01 AM, dario.re...@me.com wrote:
>
> Anand,
>
> thanks for the explanation. I'm still a little puzzled why curl behaves so
> strange. I will check how other client behave as soon as I have a chance.
>
> Vinod,
>
> what exactly is the benefit of using recordio here? Doesn't it make the
> content-type somewhat wrong? If I send 'Accept: application/json' and
> receive 'Content-Type: application/json', I actually expect to receive only
> json in the message.
>
> Thanks,
> Dario
>
> On 28.08.2015, at 18:13, Vinod Kone  wrote:
>
> I'm happy to add the "\n" after the event (note it's different from chunk)
> if that makes CURL play nicer. I'm not sure about the "\r" part though? Is
> that a nice to have or does it have some other benefit?
>
> The design doc is not set in the stone since this has not been released
> yet. So definitely want to do the right/easy thing.
>
> On Fri, Aug 28, 2015 at 7:53 AM, Anand Mazumdar 
> wrote:
>
>> Dario,
>>
>> Thanks for the detailed explanation and for trying out the new API.
>> However, this is not a bug. The output from CURL is the encoding used by
>> Mesos for the events stream. From the user doc
>> :
>>
>> *"Master encodes each Event in RecordIO format, i.e., string
>> representation of length of the event in bytes followed by JSON or binary
>> Protobuf  (possibly compressed) encoded event. Note that the value of
>> length will never be ‘0’ and the size of the length will be the size of
>> unsigned integer (i.e., 64 bits). Also, note that the RecordIO encoding
>> should be decoded by the scheduler whereas the underlying HTTP chunked
>> encoding is typically invisible at the application (scheduler) layer.“*
>>
>> If you run CURL with tracing enabled i.e. —trace, the output would be
>> something similar to this:
>>
>> <= Recv header, 2 bytes (0x2)
>> : 0d 0a   ..
>> <= Recv data, 115 bytes (0x73)
>> : 36 64 0d 0a 31 30 35 0a 7b 22 73 75 62 73 63 72 6d..105.{"subscr
>> 0010: 69 62 65 64 22 3a 7b 22 66 72 61 6d 65 77 6f 72 ibed":{"framewor
>> 0020: 6b 5f 69 64 22 3a 7b 22 76 61 6c 75 65 22 3a 22 k_id":{"value":"
>> 0030: 32 30 31 35 30 38 32 35 2d 31 30 33 30 31 38 2d 20150825-103018-
>> 0040: 33 38 36 33 38 37 31 34 39 38 2d 35 30 35 30 2d 3863871498-5050-
>> 0050: 31 31 38 35 2d 30 30 31 30 22 7d 7d 2c 22 74 79 1185-0010"}},"ty
>> 0060: 70 65 22 3a 22 53 55 42 53 43 52 49 42 45 44 22 pe":"SUBSCRIBED"
>> 0070: 7d 0d 0a}..
>> >
>> In the output above, the chunks are correctly delimited by ‘CRLF' (0d 0a)
>> as per the HTTP RFC. As mentioned earlier, the output that you observe on
>> stdout with CURL is of the Record-IO encoding used for the events stream (
>> and is not related to the RFC ):
>>
>> event = event-size LF
>>  event-data
>>
>> Looking forward to more bug reports as you try 

Re: mesos-slave crashing with CHECK_SOME

[Steven Schlansker]

On Aug 31, 2015, at 11:54 AM, Scott Rankin  wrote:
> 
> tag=mesos-slave[12858]:  F0831 09:37:29.838184 12898 slave.cpp:3354] 
> CHECK_SOME(os::touch(path)): Failed to open file: No such file or directory 

I reported a similar bug a while back:

https://issues.apache.org/jira/browse/MESOS-2684

This seems to be a class of bugs where some filesystem operations which may 
fail for unforeseen reasons are written as assertions which crash the process, 
rather than failing only the task and communicating back the error reason.

Re: Recommended way to discover current master

[Christos Kozyrakis]

If you have mesos DNS there, access leader.mesos :)

Sent from Christos' phone. 

> On Aug 31, 2015, at 10:25 AM, Philip Weaver  wrote:
> 
> My framework knows the list of zookeeper hosts and the list of mesos master 
> hosts.
> 
> I can think of a few ways for the framework to figure out which host is the 
> current master. What would be the best? Should I check in zookeeper directly? 
> Does the mesos library expose an interface to discover the master from 
> zookeeper or otherwise? Should I just try each possible master until one 
> responds?
> 
> Apologies if this is already well documented, but I wasn't able to find it. 
> Thanks!
> 
> - Philip
> 

mesos-master resource offer details

[Haripriya Ayyalasomayajula]

Hello,

I'm having trouble with some basic details:

1. I am trying to see the details of the resource offer made by the mesos
master. I can see in the logs that there are 5 resource offers made but I
am not sure where to get the details of the resource offers - the cpu,
memory etc.

2. How can I list the number of slaves registered with the master and the
details of the slaves on the command line( apart from seeing it in the UI)?

Thanks for the help.

-- 
Regards,
Haripriya Ayyalasomayajula

Re: Mesos-master complains about quorum being a duplicate flag on CoreOS

[Marco Massenzio]

Command line flags are parsed using stout/flags.hpp[0] and the FlagsBase
class is derived in mesos::internal::master::Flags (see
src/master/flags.hpp[1]).

I am not sure why you are seeing that behavior on CoreOS, but I'd be
curious to know what happens if you omit the --quorum when you start
master: it should usually fail and complain that it's a required flag (when
used in conjunction with --zk).  If it works, it will emit in the logs
(towards the very beginning) all the values of the flags: what does it say
about --quorum?

Completely random question: I assume you don't already have in the
environment a MESOS_QUORUM variable exported?

If the issue persists in a "clean" OS install and a recent build, it's
definitely a bug: it'd be great if you could please file a ticket at
http://issues.apache.org/jira (feel free to assign to me).

Thanks!

[0]
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp
[1]
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/master/flags.hpp

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com *

On Sun, Aug 30, 2015 at 8:21 PM, F21  wrote:

> I've gotten the mesos binaries compiled and packaged and deployed them
> onto a CoreOS instance.
>
>
> When I run the master, it complains that the quorum flag is duplicated:
>
> $ ./mesos-master --zk=zk://192.168.1.4/mesos --quorum=1
> --hostname=192.168.1.4 --ip=192.168.1.4
> Duplicate flag 'quorum' on command line
> ...
>
> However, if I try and run mesos-master on Ubuntu 15.04 64-bit (where the
> binaries were built), it seems to work properly:
>
> $ ./mesos-master --zk=zk://192.168.1.4/mesos --quorum=1
> --hostname=192.168.1.4 --ip=192.168.1.4
>
> I0830 18:31:20.983999 2830 main.cpp:181] Build: 2015-08-30 10:11:54 by
> I0830 18:31:20.984246 2830 main.cpp:183] Version: 0.23.0
> I0830 18:31:20.984694 2830 main.cpp:204] Using 'HierarchicalDRF'
> allocator --work_dir needed for replicated log based registry
>
> How are the command line flags parsed in mesos? What causes this strange
> behavior on CoreOS?
>
>
>

How is task mem usage calculated

[Clarke, Trevor]

In the master UI for task status there's an allocated and used value for the 
task. Allocated seems to correspond to the amount requested by the scheduler 
but I can't seem to figure out how Used is calculated. For mesos command tasks 
it doesn't look like it matches virtual or real mem usage in top. What is this 
value representing (in command tasks and docker tasks?) Currently using 0.21.1 
but will be upgrading somewhat soon so if the answer is different for 0.23 
that's also useful information.



Thanks,

Trevor



This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.