Re: Unzip should work in non interactive mode

[Jie Yu]

I can shepherd it. Do you have a patch ready?

- Jie

On Fri, Mar 18, 2016 at 3:13 AM, Tomek Janiszewski 
wrote:

> Hi
>
> Consider situation when deployed zip file is malformed and contains
> duplicated files .
> When fetcher downloads malformed zip file, that contains duplicated files
> (e.g., dist zips generated by gradle) and try to uncompress it, deployment
> hang in staged phase because unzip prompt if file should be replaced. unzip
> should overwrite this file or break with error. I created issue for this
> MESOS-4885
> It looks like easy fix, anyone want to shepherd it?
>
> Best
> Tomek
>

Re: Looking for a shepherd for MESOS-4878

[Jie Yu]

Shuai, thanks for the patch. Taking a look at it now.

On Thu, Mar 17, 2016 at 8:30 PM, Shuai Lin  wrote:

> Ping.
>
>
> On Thu, Mar 10, 2016 at 3:55 PM, Shuai Lin  wrote:
>
>> The bug is: if a framework launches a task with mesos containerizer and a
>> docker image, and the slave failed to fetch the image for any reason, the
>> task state would be stuck in STAGING forever.
>>
>> https://issues.apache.org/jira/browse/MESOS-4878
>>
>> @jieyu can you shepherd it? Thanks!
>>
>
>

Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)

[Jie Yu]

I like the idea of using branches to manage releases.

We can use that to manage point releases and backports as well.

Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
branch. Once the RC is accepted, the head of that branch will become the
release.

Then, we immediate fork that branch and create 0.29.1 branch.

When a new bug fix is committed on the trunk, the committer will decide
whether it'll affect the old releases (a bounded number, we can decide that
later). If it does, the committer of that patch should also cherry-pick
that patch to the point releases (e.g., 0.29.1 in this case). We can do a
timely based point releases.

- Jie

On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang  wrote:

> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu  wrote:
> > Cong Wang,
> >
> > The tags are sync'd.  See: https://github.com/apache/mesos/releases
> >
> > You might not have done: git pull --tags
>
>
> Yeah, I figured it out by myself too. This is why I hate tags personally,
> branches are better since they are fetched without additional parameters.
>
> Any reason why Mesos maintainers picked tags over branches to manage
> releases? Just curious...
>

0.28.1

[Jie Yu]

Hi,

We recently noticed two bugs

in
0.28.0 related to the unified containerizer:

Because of that, I propose we cut a point release (0.28.1) once these two
bugs are fixed. I volunteer to be the release manager for this point
release.

In the meantime, if you have any issue that you want to merge into 0.28.1,
please mark the relevant ticket's fix version to be 0.28.1 so that I am
aware of that.

Thanks!
- Jie

Re: Looking for shepherd (MESOS-4355 - Docker Volume Isolator)

[Jie Yu]

Guangya, I'd be happy to shepherd this work if no other committers
volunteer for this work.

- Jie

On Thu, Mar 17, 2016 at 6:05 AM, Guangya Liu  wrote:

> Hi,
>
> I was now working on the FS for MESOS-4355 with some EMC guys, can anyone
> help shepherd for this? There are some issues need to discuss with the
> shepherd.
>
> Thanks,
>
> Guangya
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

>
> You don't need LTS as kernel, even talking about short term stable releases
> like 0.27.2 (?), they look horrible too, I don't see any git tags or
> branches for
> these releases, just a tar ball?! Huh...


Jies-MacBook-Pro:mesos jie$ git tag | grep 0.27
0.27.0
0.27.0-rc1
0.27.0-rc2
0.27.1
0.27.1-rc1
0.27.2
0.27.2-rc1

What determines which patches need to backport for Mesos community?
> It doesn't look like every bug fix is evaluated and considered after they
> are merged into master branch.


Currently, it's based on request. We definitely need to improve this part.
Note that, Mesos is a fast moving project and is young. Comparing it to
Linux (20+ years) is not a fair comparison.

On Wed, Mar 16, 2016 at 11:44 AM, Cong Wang <cw...@twopensource.com> wrote:

> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yujie@gmail.com> wrote:
> > Mesos currently has no notion of long term stable releases (i.e., LTS). I
> > think the consensus in the last community sync was to introduce LTS after
> > 1.0.
>
>
> You don't need LTS as kernel, even talking about short term stable releases
> like 0.27.2 (?), they look horrible too, I don't see any git tags or
> branches for
> these releases, just a tar ball?! Huh...
>
>
> >
> > 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> > backport it.
>
>
> What determines which patches need to backport for Mesos community?
> It doesn't look like every bug fix is evaluated and considered after they
> are merged into master branch.
>
> >
> > I am OK with back porting it. Then the question is that whether we want
> to
> > backport it to other releases as well.
> >
>
> It should be backported to whichever releases it applies to and you
> support,
> I don't see Mesos community has such a procedure.
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Zhitao, that's a fair point. Can you add an agenda item to the next
community sync to discuss this? Thanks!

- Jie

On Wed, Mar 16, 2016 at 12:16 PM, Zhitao Li <zhitaoli...@gmail.com> wrote:

> Maybe we can try to draft a formal guideline about when/how something
> should be back ported, and making sure interested parties in the community
> have chance to get their voices heard?
>
> I'm also interested in knowing how much work it generates when they cut
> with back port releases, and how the community could help.
>
> On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang <cw...@twopensource.com>
> wrote:
>
> > On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yujie@gmail.com> wrote:
> > >
> > > Currently, it's based on request. We definitely need to improve this
> > part.
> >
> >
> > It simply doesn't work, like many other review requests are burned or
> take
> > 6+ months to merge. I am sure you need to improve that too, but after
> > watching Mesos community for months, I don't see any improvement yet.
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Jie Yu]

Kevin, are you suggesting option 2 and having a config file like the above?

I think another downside of a per-agent config is that it's hard to
maintain this. What if a new framework joins and has a new credential for
the docker images. Do we need to restart the agent to reload the config?

- Jie

On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues <klue...@gmail.com> wrote:

> Can we be a bit more concrete here and try to build up a schema for this.
> Maybe something like:
>
> {
>   [
> {
>   "service" : "docker",
>   "registries" :
>   [
> "uri" : "",
> "default_credentials" :
> {
>   "type" : "",
>   "credential" :
>   {
>   // Custom based on type...
>   }
> },
> "image_credentials" :
> [
>   {
> "image_name" : "",
> "type" : "",
> "credential" :
> {
>   // Custom based on type...
> },
>   },
>   ...
> ],
> ...
>   ]
>   ...
> },
> ...
>   ]
> }
>
>
> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu <yujie@gmail.com> wrote:
> >>
> >> Yeah I was thinking having the JSON as a dictionary with keys being the
> >> registry URI (appc/docker) and the values being credentials (which will
> be
> >> a dictionary as well I guess).
> >
> >
> > Using registry URI as the key is problematic. Think about the public
> docker
> > hub. Different frameworks might want to use different credentials to
> access
> > their docker images.
> >
> > - Jie
> >
> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan <
> avin...@mesosphere.io
> >
> > wrote:
> >
> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone <vinodk...@apache.org>
> wrote:
> >>
> >> > moved core@ to *bcc*
> >> >
> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> >> avin...@mesosphere.io
> >> > > wrote:
> >> >
> >> >> Why not follow option 2, but instead of passing the agent
> credentials,
> >> >> pass a location to the flag where credentials for the registry can be
> >> found
> >> >> (in JSON)? The frameworks can set credentials (maybe registry name or
> >> URL
> >> >> to the registry), and the credentials can be learnt from the JSON
> >> config.
> >> >>
> >> >
> >> > What if we need credentials for multiple-registries? Have a JSON with
> one
> >> > credential per registry I guess? But if possible, I would love to
> solve
> >> > this more generally as possible; as Gilbert mentioned, this is not a
> >> > problem just for Docker images but any URIs that need AuthN.
> >> >
> >> Yeah I was thinking having the JSON as a dictionary with keys being the
> >> registry URI (appc/docker) and the values being credentials (which will
> be
> >> a dictionary as well I guess).
> >>
> >>
> >> --
> >> Avinash Sridharan, Mesosphere
> >> +1 (323) 702 5245
> >>
>
>
>
> --
> ~Kevin
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
Author: Jojy Varghese <j...@mesosphere.io>
Date:   Tue Mar 15 17:12:01 2016 -0700

Added support for FTS_SLNONE in rmdir.

Review: https://reviews.apache.org/r/44874/

commit 5c4b348c8090ce61804b7701e3b0705ced975a7e
Author: Jojy Varghese <j...@mesosphere.io>
Date:   Tue Mar 15 17:11:54 2016 -0700

Added test for rmdir with device file.

Existing tests did not cover the case of removing directories with
special files like device files.

Review: https://reviews.apache.org/r/44873/

- Jie

On Tue, Mar 15, 2016 at 2:46 PM, Jie Yu <yujie@gmail.com> wrote:
> Also, I think we should fix the TODO in rmdir as well (i.e., handle
> FTS_SLNONE as well as Neil suggested).
>
> - Jie
>
> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yujie@gmail.com> wrote:
>>
>> Mesos currently has no notion of long term stable releases (i.e., LTS). I
>> think the consensus in the last community sync was to introduce LTS after
>> 1.0.
>>
>> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
>> backport it.
>>
>> I am OK with back porting it. Then the question is that whether we want to
>> backport it to other releases as well.
>>
>> - Jie
>>
>> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang <cw...@twopensource.com>
>> wrote:
>>>
>>> Hi, all
>>>
>>> I don't know what is the process to request for a backport for Mesos
>>> stable releases and how Mesos community cares about stable releases.
>>> But... please consider to backport the following patch to at least
>>> 0.27 branch:
>>>
>>> https://reviews.apache.org/r/44230/
>>>
>>> It fixes a bug in our production which causes GC failed to prune a
>>> directory.
>>>
>>> The backport should be very straightforward. Please let me know if I
>>> can help anything.
>>>
>>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>>> backported to the right stable releases.
>>>
>>> Thanks.
>>
>>
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Also, I think we should fix the TODO in rmdir as well (i.e.,
handle FTS_SLNONE as well as Neil suggested).

- Jie

On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yujie@gmail.com> wrote:

> Mesos currently has no notion of long term stable releases (i.e., LTS). I
> think the consensus in the last community sync was to introduce LTS after
> 1.0.
>
> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> backport it.
>
> I am OK with back porting it. Then the question is that whether we want to
> backport it to other releases as well.
>
> - Jie
>
> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang <cw...@twopensource.com>
> wrote:
>
>> Hi, all
>>
>> I don't know what is the process to request for a backport for Mesos
>> stable releases and how Mesos community cares about stable releases.
>> But... please consider to backport the following patch to at least
>> 0.27 branch:
>>
>> https://reviews.apache.org/r/44230/
>>
>> It fixes a bug in our production which causes GC failed to prune a
>> directory.
>>
>> The backport should be very straightforward. Please let me know if I
>> can help anything.
>>
>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>> backported to the right stable releases.
>>
>> Thanks.
>>
>
>

Re: Backport r/44230 to 0.27 branch

[Jie Yu]

Mesos currently has no notion of long term stable releases (i.e., LTS). I
think the consensus in the last community sync was to introduce LTS after
1.0.

0.27.2 has already been released. Looks like we need 0.27.3 if we want to
backport it.

I am OK with back porting it. Then the question is that whether we want to
backport it to other releases as well.

- Jie

On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang  wrote:

> Hi, all
>
> I don't know what is the process to request for a backport for Mesos
> stable releases and how Mesos community cares about stable releases.
> But... please consider to backport the following patch to at least
> 0.27 branch:
>
> https://reviews.apache.org/r/44230/
>
> It fixes a bug in our production which causes GC failed to prune a
> directory.
>
> The backport should be very straightforward. Please let me know if I
> can help anything.
>
> BTW, for Linux kernel we evaluate every bug fix to make sure it is
> backported to the right stable releases.
>
> Thanks.
>

Re: [DISCUSS] Fetching Docker Images Requiring User Credentials.

[Jie Yu]

>
> Yeah I was thinking having the JSON as a dictionary with keys being the
> registry URI (appc/docker) and the values being credentials (which will be
> a dictionary as well I guess).


Using registry URI as the key is problematic. Think about the public docker
hub. Different frameworks might want to use different credentials to access
their docker images.

- Jie

On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan 
wrote:

> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone  wrote:
>
> > moved core@ to *bcc*
> >
> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> avin...@mesosphere.io
> > > wrote:
> >
> >> Why not follow option 2, but instead of passing the agent credentials,
> >> pass a location to the flag where credentials for the registry can be
> found
> >> (in JSON)? The frameworks can set credentials (maybe registry name or
> URL
> >> to the registry), and the credentials can be learnt from the JSON
> config.
> >>
> >
> > What if we need credentials for multiple-registries? Have a JSON with one
> > credential per registry I guess? But if possible, I would love to solve
> > this more generally as possible; as Gilbert mentioned, this is not a
> > problem just for Docker images but any URIs that need AuthN.
> >
> Yeah I was thinking having the JSON as a dictionary with keys being the
> registry URI (appc/docker) and the values being credentials (which will be
> a dictionary as well I guess).
>
>
> --
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245
>

Re: RFC: RevocableInfo Changes

[Jie Yu]

>
> Just a quick note: Ian D. and the performance isolation working group are
> discussing similar annotations and we should meet and talk about the
> options.


+1

Would love to understand the relationship between this and the
task/executor level annotations.

- Jie

On Mon, Mar 14, 2016 at 9:29 AM, Niklas Nielsen  wrote:

> Hi Ben,
>
> Just a quick note: Ian D. and the performance isolation working group are
> discussing similar annotations and we should meet and talk about the
> options.
>
> Niklas
>
> On Sat, Mar 12, 2016 at 12:05 AM, Klaus Ma  wrote:
>
> > Yes, I think that's true for now; so we define `ThrottleInfo` as message
> to
> > be more flexible. In Optimistic Offer Phase 1, we only use it to
> > distinguish usage oversubscriptions and allocation oversubscription,
> > similar to bool :).
> >
> > Regarding the resources type, two questions after the discussion:
> >
> > 1. should we send different offer to the framework, so when
> > usage/allocation oversubscription updated, only one type of offer will be
> > rescinded?
> > 2. should we define framework's capability against `ThrottleInfo`?
> >
> > 
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform OpenSource Technology, STG, IBM GCG
> > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >
> > On Sat, Mar 12, 2016 at 12:03 PM, Guangya Liu 
> wrote:
> >
> > >
> > > Hi Ben,
> > >
> > > I think that currently and even in the near future, the
> __ThrottleInfo__
> > > will only be used by the usage oversubscriptions and the
> oversubscription
> > > for allocator (Both quota and reservations) will not use this value but
> > > only using __RevocableInfo__ is enough.
> > >
> > > I can even think that the __ThrottleInfo__ as a boolean value in
> > > optimistic offer phase 1 as it is mainly used to distinguish resources
> > > between usage oversubscriptions and allocation oversubscription (Quota
> > and
> > > Reservations), comments?
> > >
> > > Thanks,
> > >
> > > Guangya
> > >
> > > 在 2016年3月12日星期六 UTC+8上午11:09:46，Benjamin Mahler写道：
> > >
> > >> Hey folks,
> > >>
> > >> In the resource allocation working group we've been looking into a few
> > >> projects that will make the allocator able to offer out resources as
> > >> revocable. For example:
> > >>
> > >> -We'll want to eventually allocate resources as revocable _by
> default_,
> > >> only allowing non-revocable when there are guarantees put in place
> > (static
> > >> reservations or quota).
> > >>
> > >> -On the path to revocable by default, we can incrementally start to
> > offer
> > >> certain resources as revocable. Consider when quota is set but the
> role
> > >> isn't using all of the quota. The unallocated quota can be offered to
> > other
> > >> roles, but it should be revocable because we may revoke them should
> the
> > >> quota'ed role want to use the resources. Unused reservations fall
> into a
> > >> similar category.
> > >>
> > >> -Going revocable by default also allows us to enforce fairness in a
> > >> dynamically changing cluster by revoking resources as weights are
> > changed,
> > >> frameworks are added or removed, etc.
> > >>
> > >> In this context, "revocable" means that the resources may be taken
> away
> > >> and the container will be destroyed. The meaning of "revocable" in the
> > >> context of usage oversubscription includes this, but also the
> container
> > may
> > >> experience a throttling (e.g. lower cpu shares, less network priority,
> > etc).
> > >>
> > >> For this reason, and because we internally need to distinguish
> revocable
> > >> resources between the those that are generated by usage
> oversubscription
> > >> and those that are generated by the allocator, we're thinking of the
> > >> following change to the API:
> > >>
> > >>
> > >>
> > >> -  message RevocableInfo {}
> > >> +  message RevocableInfo {
> > >> +message ThrottleInfo {}
> > >> +
> > >> +// If set, indicates that the resources may be throttled at
> > >> +// any time. Throttle-able resoruces can be used for tasks
> > >> +// that do not have strict performance requirements and are
> > >> +// capable of handling being throttled.
> > >> +optional ThrottleInfo throttle_info;
> > >> +  }
> > >>
> > >>// If this is set, the resources are revocable, i.e., any tasks or
> > >> -  // executors launched using these resources could get preempted or
> > >> -  // throttled at any time. This could be used by frameworks to run
> > >> -  // best effort tasks that do not need strict uptime or performance
> > >> +  // executors launched using these resources could be terminated at
> > >> +  // any time. This could be used by frameworks to run
> > >> +  // best effort tasks that do not need strict uptime
> > >>// guarantees. Note that if this is set, 'disk' or 'reservation'
> > >>// cannot be set.
> > >>optional RevocableInfo revocable = 9;
> > >>
> > >>
> > >>
> > >> Essentially we 

Re: mesos git commit: Add 'name' field into NetworkInfo.

[Jie Yu]

Good catch.

+ Qian, could you please send a patch for that? Thanks!

- Jie

On Thu, Mar 10, 2016 at 11:08 AM, Neil Conway <neil.con...@gmail.com> wrote:

> Should we also update docs/networking-for-mesos-managed-containers.md?
> It contains a version of the NetworkInfo message definition.
>
> Neil
>
> On Thu, Mar 10, 2016 at 11:05 AM,  <ji...@apache.org> wrote:
> > Repository: mesos
> > Updated Branches:
> >   refs/heads/master 57a574fc9 -> 2a436e02f
> >
> >
> > Add 'name' field into NetworkInfo.
> >
> > Review: https://reviews.apache.org/r/44004/
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/2a436e02
> > Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/2a436e02
> > Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/2a436e02
> >
> > Branch: refs/heads/master
> > Commit: 2a436e02f7f475e2d7264c6a4b58dd557bfec883
> > Parents: 57a574f
> > Author: Qian Zhang <zhang...@cn.ibm.com>
> > Authored: Thu Mar 10 11:04:59 2016 -0800
> > Committer: Jie Yu <yujie@gmail.com>
> > Committed: Thu Mar 10 11:04:59 2016 -0800
> >
> > --
> >  include/mesos/mesos.proto| 5 +
> >  include/mesos/v1/mesos.proto | 5 +
> >  src/common/http.cpp  | 8 
> >  3 files changed, 18 insertions(+)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2a436e02/include/mesos/mesos.proto
> > --
> > diff --git a/include/mesos/mesos.proto b/include/mesos/mesos.proto
> > index 3d22ec3..56d456a 100644
> > --- a/include/mesos/mesos.proto
> > +++ b/include/mesos/mesos.proto
> > @@ -1581,6 +1581,11 @@ message NetworkInfo {
> >// this field is filled in automatically with the Agent IP address.
> >repeated IPAddress ip_addresses = 5;
> >
> > +  // Name of the network which will be used by network isolator to
> determine
> > +  // the network that the container joins. It's up to the network
> isolator
> > +  // to decide how to interpret this field.
> > +  optional string name = 6;
> > +
> >// Specify IP address requirement. Set protocol to the desired value
> to
> >// request the network isolator on the Agent to assign an IP address
> to the
> >// container being launched. If a specific IP address is specified in
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2a436e02/include/mesos/v1/mesos.proto
> > --
> > diff --git a/include/mesos/v1/mesos.proto b/include/mesos/v1/mesos.proto
> > index 31960a5..4fba774 100644
> > --- a/include/mesos/v1/mesos.proto
> > +++ b/include/mesos/v1/mesos.proto
> > @@ -1578,6 +1578,11 @@ message NetworkInfo {
> >// this field is filled in automatically with the Agent IP address.
> >repeated IPAddress ip_addresses = 5;
> >
> > +  // Name of the network which will be used by network isolator to
> determine
> > +  // the network that the container joins. It's up to the network
> isolator
> > +  // to decide how to interpret this field.
> > +  optional string name = 6;
> > +
> >// Specify IP address requirement. Set protocol to the desired value
> to
> >// request the network isolator on the Agent to assign an IP address
> to the
> >// container being launched. If a specific IP address is specified in
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2a436e02/src/common/http.cpp
> > --
> > diff --git a/src/common/http.cpp b/src/common/http.cpp
> > index be8538f..3e92979 100644
> > --- a/src/common/http.cpp
> > +++ b/src/common/http.cpp
> > @@ -203,6 +203,10 @@ JSON::Object model(const NetworkInfo& info)
> >  object.values["ip_addresses"] = std::move(array);
> >}
> >
> > +  if (info.has_name()) {
> > +object.values["name"] = info.name();
> > +  }
> > +
> >return object;
> >  }
> >
> > @@ -528,6 +532,10 @@ void json(JSON::ObjectWriter* writer, const
> NetworkInfo& info)
> >}
> >  });
> >}
> > +
> > +  if (info.has_name()) {
> > +writer->field("name", info.name());
> > +  }
> >  }
> >
> >
> >
>

Re: Executors no longer inherit environment variables from the agent

[Jie Yu]

Alex,

See my response inlined:

First, does this change include the executor library? We currently use
> environment variables to propagate various config values from an agent to
> executors. If it does, what is the alternative?


Any environment variables generated by Mesos (i.e., MESOS_, LIBPROCESS_)
will not be affected.

Second, what will be the preferred way to pass config values to executors?
> It would be great to be able to do it uniformly for non-HTTP and HTTP
> executors. I can think of several possibilities: cmd flags, adding or
> overriding protobufs, extending Executor interface.


You can always use the Environments in ExecutorInfo.CommandInfo or
TaskInfo.CommandInfo to pass in environment variables to executors/tasks.

- Jie

On Thu, Mar 10, 2016 at 3:50 AM, Alex Rukletsov  wrote:

> I have two questions.
>
> First, does this change include the executor library? We currently use
> environment variables to propagate various config values from an agent to
> executors. If it does, what is the alternative?
>
> Second, what will be the preferred way to pass config values to executors?
> It would be great to be able to do it uniformly for non-HTTP and HTTP
> executors. I can think of several possibilities: cmd flags, adding or
> overriding protobufs, extending Executor interface.
>
> On Tue, Mar 8, 2016 at 9:21 PM, Gilbert Song 
> wrote:
>
>> Yes, `LIBPROCESS_IP` will be excepted from this change. We will still
>> have `LIBPROCESS_IP` set and passed to executors' environment, which is for
>> the case that DNS is not available on the slave.
>>
>> Gilbert
>>
>> On Tue, Mar 8, 2016 at 11:57 AM, Zhitao Li  wrote:
>>
>>> Is LIBPROCESS_IP going to be an exception to this? Some executors are
>>> using this variable as an alternative of implementing their own IP
>>> detection logic AFAIK so this behavior would break them.
>>>
>>> On Tue, Mar 8, 2016 at 11:33 AM, Gilbert Song 
>>> wrote:
>>>
 Hi,

 TL;DR Executors will no longer inherit environment variables from the
 agent by default in 0.30.

 Currently, executors are inheriting environment variables form the
 agent in mesos containerizer by default. This is an unfortunate legacy
 behavior and is insecure. If you do have environment variables that you
 want to pass to the executors, you can set it explicitly by using the
 `--executor_environment_variables` agent flag.

 Starting from 0.30, we will no longer allow executors to inherit
 environment variables from the agent. In other words,
 `--executor_environment_variables` will be set to “{}” by default. If you
 do depend on the original behavior, please set
 `--executor_environment_variables` flag explicitly.

 Let us know if you have any comments or concerns.

 Thanks,
 Gilbert

>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>

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

[Jie Yu]

I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as well if
you guys plan to cut another RC

On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
daniel.osbo...@metaswitch.com> wrote:

> -1
>
> If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively
> small patch which restores Mesos' ability to extract Docker assigned IPs.
> This has been broken with Docker 1.10's release over  a month ago, and
> prevents service discovery and DNS from working.
>
> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
> RB# 43093: https://reviews.apache.org/r/43093/
>
> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as
> expected.
>
> Apologies for not bringing this to attention earlier.
>
> Thanks all,
> Dan
>
> -Original Message-
> From: Vinod Kone [mailto:vinodk...@apache.org]
> Sent: Thursday, March 3, 2016 5:44 PM
> To: dev ; user 
> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>
>
> 0.28.0 includes the following:
>
>
> 
>
>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> subsystem in
>
> Linux. The cgroups/net_cls isolator allows operators to provide network
>
>
> performance isolation and network segmentation for containers within a
> Mesos
>
> cluster. To enable the cgroups/net_cls isolator, append
> `cgroups/net_cls` to
>
> the `--isolation` flag when starting the slave. Please refer to
>
>
> docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4687] - The implementation of scalar resource values (e.g., "2.5
>
>
> CPUs") has changed. Mesos now reliably supports resources with up to
> three
>
> decimal digits of precision (e.g., "2.501 CPUs"); resources with more
> than
>
> three decimal digits of precision will be rounded. Internally,
> resource math
>
> is now done using a fixed-point format that supports three decimal
> digits of
>
> precision, and then converted to/from floating point for input and
> output,
>
> respectively. Frameworks that do their own resource math and manipulate
>
>
> fractional resources may observe differences in roundoff error and
> numerical
>
> precision.
>
>
>
>
>
>   * [MESOS-4479] - Reserved resources can now optionally include "labels".
>
>
> Labels are a set of key-value pairs that can be used to associate
> metadata
>
> with a reserved resource. For example, frameworks can use this feature
> to
>
> distinguish between two reservations for the same role at the same
> agent
>
> that are intended for different purposes.
>
>
>
>
>
>   * [MESOS-2840] - **Experimental** support for container images in Mesos
>
>
> containerizer (a.k.a. Unified Containerizer). This allows frameworks to
>
>
> launch Docker/Appc containers using Mesos containerizer without
> relying on
>
> docker daemon (engine) or rkt. The isolation of the containers is done
> using
>
> isolators. Please refer to docs/container-image.md for currently
> supported
>
> features and limitations.
>
>
>
>
>
>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This
>
>
> allows executors to send HTTP requests to the /api/v1/executor agent
>
>
> endpoint without the need for an executor driver. Please refer to
>
>
> docs/executor-http-api.md for more details.
>
>
>
>
>
> Additional API Changes:
>
>
>   * [MESOS-4066] - Agent should not return partial state when a request is
> made to /state endpoint during recovery.
>
>   * [MESOS-4547] - Introduce TASK_KILLING state.
>
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-3583] - Add stream IDs for HTTP schedulers.
>
>
> The CHANGELOG for the release is available at:
>
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc1
>
>
> 
>
>
> The candidate for Mesos 0.28.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz
>
>
> The tag to be voted on is 0.28.0-rc1:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.0-rc1
>
>
> The MD5 checksum of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.asc
>
>
> The PGP key used to 

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

[Jie Yu]

Steven, sorry about the delay. I'll finish the doc today.

On Fri, Mar 4, 2016 at 10:29 AM, Steven Schlansker <
sschlans...@opentable.com> wrote:

>
> > On Mar 3, 2016, at 5:43 PM, Vinod Kone  wrote:
> >
> > Hi all,
> > Please vote on releasing the following candidate as Apache Mesos 0.28.0.
> > 0.28.0 includes the following:
> > ...
> >   * [MESOS-2840] - **Experimental** support for container images in Mesos
> > containerizer (a.k.a. Unified Containerizer). This allows frameworks
> to
> > launch Docker/Appc containers using Mesos containerizer without
> relying on
> > docker daemon (engine) or rkt. The isolation of the containers is
> done using
> > isolators. Please refer to docs/container-image.md for currently
> supported
> > features and limitations.
>
> As of commit 46dcae5, there doesn't seem to be any such documentation?
> I'm excited to try this feature out :)
>
> https://github.com/apache/mesos/blob/master/docs/container-image.md (404)
>
>

Re: Making 'curl' a prerequisite for installing Mesos

[Jie Yu]

Thanks for the feedback, guys!

I think we all agree that using libcurl is the ideal solution. I've already
created a ticket for this:
https://issues.apache.org/jira/browse/MESOS-4853

Currently, only docker/appc image puller is using 'curl' directly. I guess
it's not a problem on Windows yet.

Based on the discussion, I won't add a 'curl' dependency to Mesos. Instead,
I'll mention the 'curl' dependency in the doc of container image support
for now. Hopefully, we can remove that dependency soon when MESOS-4853 is
addressed.

Thanks,
- Jie

On Fri, Mar 4, 2016 at 12:00 PM, Alexander Rojas <alexan...@mesosphere.io>
wrote:

> I also have my doubts about this idea. Given that we support some legacy
> systems and the user interface tends to be less stable than an API (though
> comparing the flags between curl 7.38.0 in Debian 8 and curl 7.19.7 in
> CentOS 6.7, I don’t see a lot of differences in the important ones).
>
> So I guess what I am trying to say is, if we go this route, let’s make
> sure it is fully compatible across versions and the behavior is uniform.
>
>
> > On 03 Mar 2016, at 18:39, Alex Clemmer <clemmer.alexan...@gmail.com>
> wrote:
> >
> > Looks like the relevant review is this one:
> > https://reviews.apache.org/r/40418/diff/3#4
> >
> > I _suspect_ this will work with Windows, but am not positive.
> > Optimistically, it's not clear to me whether it makes sense to add it
> > as a dependency, because I don't know how to get its location reliably
> > on Windows. Because Windows has no package manager, we actually rope
> > it in the libcurl dependency from CMake, at build time. Seems like the
> > thing to do might be to just build the exe as well and dispatch to
> > that but this will require some modifications to this code.
> >
> > On Thu, Mar 3, 2016 at 5:46 PM, Guangya Liu <gyliu...@gmail.com> wrote:
> >> libcurl can automatically picks up certain environment variables and
> >> adjusts its settings accordingly, so libcurl support enabling http_proxy
> >> and https_proxy by default, this is important feature for someone who
> want
> >> to use a proxy to connect internet. One example is that I cannot get
> google
> >> docker images but need a proxy set in China.
> >>
> >> If we depend on "curl" (I saw that we already finished the this in
> >> MESOS-2840) when using fetcher, I think that we may also need to enable
> >> slave to pass a proxy to fetch curl to enable someone can pull google
> >> docker images under a firewall. Does it make sense file a JIRA to
> support
> >> http proxy?
> >>
> >> Thanks,
> >>
> >> Guangya
> >>
> >> On Fri, Mar 4, 2016 at 9:39 AM, Klaus Ma <klaus1982...@gmail.com>
> wrote:
> >>
> >>> +1 to add 'curl' dependency firstly.
> >>>
> >>> 
> >>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> >>> Platform OpenSource Technology, STG, IBM GCG
> >>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >>>
> >>> On Fri, Mar 4, 2016 at 5:04 AM, Jojy Varghese <j...@mesosphere.io>
> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> On Thu, Mar 3, 2016 at 12:52 PM Jake Farrell <jfarr...@apache.org>
> >>> wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> -Jake
> >>>>>
> >>>>> On Thu, Mar 3, 2016 at 12:10 PM, Jie Yu <yujie@gmail.com> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I am proposing making 'curl' a prerequisite when installing Mesos.
> >>>>>> Currently, we require 'libcurl' being present when installing Mesos
> (
> >>>>>> http://mesos.apache.org/gettingstarted/). However, we found that it
> >>>> does
> >>>>>> not compose well with our asynchronous runtime environment (i.e.,
> >>> it'll
> >>>>>> block the current worker thread).
> >>>>>>
> >>>>>> Recent work on URI fetcher
> >>>>>> <https://issues.apache.org/jira/browse/MESOS-3918> uses 'curl'
> >>>> directly,
> >>>>>> instead of using 'libcurl' to fetch artifacts, because it composes
> >>> well
> >>>>>> with our async runtime env. 'curl' is installed by default in most
> >>>>> systems
> >>>>>> (e.g., OSX, centos, RHEL).
> >>>>>>
> >>>>>> So I am proposing adding 'curl' to our prerequisite list. Let me
> know
> >>>> if
> >>>>>> you have any concern on this. I'll update the Getting Started doc if
> >>>> you
> >>>>>> are OK with this change.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> - Jie
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
>
>

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

[Jie Yu]

I am writing that as you speaking

On Fri, Mar 4, 2016 at 10:34 AM, Vinod Kone  wrote:

> I think this was supposed to refer to
> https://github.com/apache/mesos/blob/master/docs/mesos-containerizer.md
>
> @Jie ^^ ?
>
> On Fri, Mar 4, 2016 at 10:29 AM, Steven Schlansker <
> sschlans...@opentable.com> wrote:
>
>>
>> > On Mar 3, 2016, at 5:43 PM, Vinod Kone  wrote:
>> >
>> > Hi all,
>> > Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>> > 0.28.0 includes the following:
>> > ...
>> >   * [MESOS-2840] - **Experimental** support for container images in
>> Mesos
>> > containerizer (a.k.a. Unified Containerizer). This allows
>> frameworks to
>> > launch Docker/Appc containers using Mesos containerizer without
>> relying on
>> > docker daemon (engine) or rkt. The isolation of the containers is
>> done using
>> > isolators. Please refer to docs/container-image.md for currently
>> supported
>> > features and limitations.
>>
>> As of commit 46dcae5, there doesn't seem to be any such documentation?
>> I'm excited to try this feature out :)
>>
>> https://github.com/apache/mesos/blob/master/docs/container-image.md (404)
>>
>>
>

Re: Making 'curl' a prerequisite for installing Mesos

[Jie Yu]

Neil, thanks for the comments and the pointer!

Just looked at the curl_multi_xxx() API. Yeah, I think we should be able to
use that API in our async environment.  But we need to hook this with our
underlying libev/libevent based runtime, which might take a while to
finish. I'll create a ticket to track.

In the meantime, I want to unblock people from using some of the new
features built on top of the 'curl' based fetcher. Since this is a pretty
simple dependency to add, I would suggest that we still proceed adding this
dependency.

- Jie

On Thu, Mar 3, 2016 at 9:37 AM, Neil Conway <neil.con...@gmail.com> wrote:

> No objection to about the additional dependency, but using 'curl'
> instead of 'libcurl' seems unfortunate. Can you share some more
> detailed information about the problems that have been encountered
> using libcurl? e.g., was using the curl_multi_xxx() APIs explored?
>
> Neil
>
> On Thu, Mar 3, 2016 at 9:10 AM, Jie Yu <yujie@gmail.com> wrote:
> > Hi,
> >
> > I am proposing making 'curl' a prerequisite when installing Mesos.
> > Currently, we require 'libcurl' being present when installing Mesos
> > (http://mesos.apache.org/gettingstarted/). However, we found that it
> does
> > not compose well with our asynchronous runtime environment (i.e., it'll
> > block the current worker thread).
> >
> > Recent work on URI fetcher uses 'curl' directly, instead of using
> 'libcurl'
> > to fetch artifacts, because it composes well with our async runtime env.
> > 'curl' is installed by default in most systems (e.g., OSX, centos, RHEL).
> >
> > So I am proposing adding 'curl' to our prerequisite list. Let me know if
> you
> > have any concern on this. I'll update the Getting Started doc if you are
> OK
> > with this change.
> >
> > Thanks,
> > - Jie
> >
>

Making 'curl' a prerequisite for installing Mesos

[Jie Yu]

Hi,

I am proposing making 'curl' a prerequisite when installing Mesos.
Currently, we require 'libcurl' being present when installing Mesos (
http://mesos.apache.org/gettingstarted/). However, we found that it does
not compose well with our asynchronous runtime environment (i.e., it'll
block the current worker thread).

Recent work on URI fetcher
 uses 'curl' directly,
instead of using 'libcurl' to fetch artifacts, because it composes well
with our async runtime env. 'curl' is installed by default in most systems
(e.g., OSX, centos, RHEL).

So I am proposing adding 'curl' to our prerequisite list. Let me know if
you have any concern on this. I'll update the Getting Started doc if you
are OK with this change.

Thanks,
- Jie

Re: Reorganize 3rdparty directory

[Jie Yu]

>
> However, in the current code base, we don't strictly follow the 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages inside
> 3rdparty/libprocess/3rdparty/stout/3rdparty/.


My understanding is that stout is header only. So it does not have to
bundle 3rdparty libraries. The user of stout is responsible for bundling
them if they are used.

- Jie

On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya  wrote:

> Hi All,
>
> TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into 3rdparty/.
> (Optionally) Move libprocess/stout to the top-level directory.
>
> I wanted to start some discussion around reorganizing stuff inside
> "3rdparty". I apologize for the length of the email, please bear with me.
>
> Traditionally, 3rdparty has been used to hold all Mesos dependencies
> (zookeeper, libprocess, protobuf, stout, etc.). Further,
> libprocess/3rdparty was to hold all libprocess dependencies (which may in
> turn be Mesos dependencies as well).
>
> As I understand, the original motivation was to emphasize that libprocess
> is an independent project which depends on "stout", which in turn is also
> an independent project.
>
> However, in the current code base, we don't strictly follow the 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages inside
> 3rdparty/libprocess/3rdparty/stout/3rdparty/.
>
> In light of these anomalies, I want to propose that we flatten out the
> 3rdparty directory and put all packages (libprocess, stout, protobuf,
> picojson, zookeeper, etc.) at the same level in 3rdparty. We can still use
> "--with-XYZ=..." to the full extent as needed.
>
> To take it a step further, I want to propose that we bring libprocess and
> stout out of 3rdparty/ and move them at the top level (i.e., make them
> peers of src/). That way, all code in 3rdparty/ is stuff from "third"
> parties and is used only when "--with-bundled" is defined (by default).
> This hierarchy will still allow us to keep libprocess and stout as separate
> independent projects.
>
> The motivation for this proposal came when dealing with 3rdparty
> dependencies for module development. A module developer needs access to
> protobuf, picojson, glog, etc., and for that matter, the exact versions of
> these packages that Mesos was compiled with.
>
> We want to solve this problem by installing module-specific 3rdparty
> dependencies into "${pkglibdir}/3rdparty" as part of "make install" (if
> configured with something like "--enable-install-module-dependencies").
> (There is a discussion going on in a separate thread).
>
> Further, as of today, when we install Mesos using "make install", we
> install stout headers in "${prefix}/include/stout". However, stout has
> dependencies on picojson[1] and google-protobuf headers which may not be
> present on the machine. This leaves stout, and in turn libprocess and Mesos
> headers, fairly broken. I understand that this issue is somewhat orthogonal
> to the main issue being discussed in this mail, but I wanted to put it out
> since it's related.
>
> Any thoughts, comments, concerns are most welcome!
>
> Best,
> Kapil
>
>
> [1]: Picojson issue was resolved as part of
> https://reviews.apache.org/r/41424/ which installs picojson.h into the
> include-dir.
>

Re: Reorganize 3rdparty directory

[Jie Yu]

Kapil,

I guess what I want to understand is why the existing structure makes it
hard for you to do the things that you want to do (installing
module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part
of "make install").

The only reason you mentioned in the original email is that "in the current
code base, we don't strictly follow the 3rdparty structure", which IMO is
not a very convincing reason for such a big change.

- Jie

On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu <yujie@gmail.com> wrote:
> >
> > >
> > > However, in the current code base, we don't strictly follow the
> 3rdparty
> > > structure. For example, stout has a dependency on picojson and
> > > google-protobuf, but we don't put these two packages inside
> > > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
> >
> >
> > My understanding is that stout is header only. So it does not have to
> > bundle 3rdparty libraries. The user of stout is responsible for bundling
> > them if they are used.
>
>
> I don't think being header-only is an excuse to have a broken
> installation :-). Further, we don't make it easier for the user to get
> the 3rdparty binaries either. For example, if the user has a different
> version of protobuf installed on the system, the compilation of any
> program that uses stout will fail spectacularly!
>
> Having said that, the gist here is that we have somewhat deviated from
> original motivation behind the 3rdparty directory and it would be nice
> if we can have a flatter structure.
>
> >
> >
> > - Jie
> >
> > On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> >
> > > Hi All,
> > >
> > > TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into
> 3rdparty/.
> > > (Optionally) Move libprocess/stout to the top-level directory.
> > >
> > > I wanted to start some discussion around reorganizing stuff inside
> > > "3rdparty". I apologize for the length of the email, please bear with
> me.
> > >
> > > Traditionally, 3rdparty has been used to hold all Mesos dependencies
> > > (zookeeper, libprocess, protobuf, stout, etc.). Further,
> > > libprocess/3rdparty was to hold all libprocess dependencies (which may
> in
> > > turn be Mesos dependencies as well).
> > >
> > > As I understand, the original motivation was to emphasize that
> libprocess
> > > is an independent project which depends on "stout", which in turn is
> also
> > > an independent project.
> > >
> > > However, in the current code base, we don't strictly follow the
> 3rdparty
> > > structure. For example, stout has a dependency on picojson and
> > > google-protobuf, but we don't put these two packages inside
> > > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
> > >
> > > In light of these anomalies, I want to propose that we flatten out the
> > > 3rdparty directory and put all packages (libprocess, stout, protobuf,
> > > picojson, zookeeper, etc.) at the same level in 3rdparty. We can still
> use
> > > "--with-XYZ=..." to the full extent as needed.
> > >
> > > To take it a step further, I want to propose that we bring libprocess
> and
> > > stout out of 3rdparty/ and move them at the top level (i.e., make them
> > > peers of src/). That way, all code in 3rdparty/ is stuff from "third"
> > > parties and is used only when "--with-bundled" is defined (by default).
> > > This hierarchy will still allow us to keep libprocess and stout as
> separate
> > > independent projects.
> > >
> > > The motivation for this proposal came when dealing with 3rdparty
> > > dependencies for module development. A module developer needs access to
> > > protobuf, picojson, glog, etc., and for that matter, the exact
> versions of
> > > these packages that Mesos was compiled with.
> > >
> > > We want to solve this problem by installing module-specific 3rdparty
> > > dependencies into "${pkglibdir}/3rdparty" as part of "make install" (if
> > > configured with something like "--enable-install-module-dependencies").
> > > (There is a discussion going on in a separate thread).
> > >
> > > Further, as of today, when we install Mesos using "make install", we
> > > install stout headers in "${prefix}/include/stout". However, stout has
> > > dependencies on picojson[1] and google-protobuf headers which may not
> be
> > > present on the machine. This leaves stout, and in turn libprocess and
> Mesos
> > > headers, fairly broken. I understand that this issue is somewhat
> orthogonal
> > > to the main issue being discussed in this mail, but I wanted to put it
> out
> > > since it's related.
> > >
> > > Any thoughts, comments, concerns are most welcome!
> > >
> > > Best,
> > > Kapil
> > >
> > >
> > > [1]: Picojson issue was resolved as part of
> > > https://reviews.apache.org/r/41424/ which installs picojson.h into the
> > > include-dir.
> > >
>

Re: [4/4] mesos git commit: Added `Resources::size()`.

[Jie Yu]

maybe add a comment saying that size() is only used for testing.

- Jie

On Fri, Feb 5, 2016 at 6:07 PM, Michael Park  wrote:

> I also spoke to Jie about this issue, and he agreed that it'd be better to
> expose the `size` rather than people trying to compute it manually.
>
> On 5 February 2016 at 18:04, Michael Park  wrote:
>
>>
>> On 5 February 2016 at 17:15, Benjamin Mahler  wrote:
>>
>>> Didn't we pull this out in the past? I seem to remember it being too
>>> brittle to have code looking at 'size' since it depends on our changing
>>> concept of when Resource objects can be merged.
>>>
>>
>> Yep, I brought up the fact that we intentionally removed `size()` before
>> here: https://reviews.apache.org/r/42751/#comment178972. Neil brings up
>> the point that as long as we support iteration over the `Resources`, people
>> can compute the size themselves anyway and therefore is part of the public
>> API. Another situation was when we wanted to test that resources were
>> merged or not merged, there's no good way for us to test either of the
>> conditions.
>>
>>
>>> On Fri, Feb 5, 2016 at 3:16 PM,  wrote:
>>>
 Added `Resources::size()`.

 Review: https://reviews.apache.org/r/43239/


 Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
 Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/d9d966d9
 Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/d9d966d9
 Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/d9d966d9

 Branch: refs/heads/master
 Commit: d9d966d9e636fd4bee8b902742eaa9cf6dd1b342
 Parents: 2a65da0
 Author: Neil Conway 
 Authored: Fri Feb 5 14:11:33 2016 -0800
 Committer: Michael Park 
 Committed: Fri Feb 5 15:04:09 2016 -0800

 --
  include/mesos/resources.hpp| 2 ++
  include/mesos/v1/resources.hpp | 2 ++
  2 files changed, 4 insertions(+)
 --



 http://git-wip-us.apache.org/repos/asf/mesos/blob/d9d966d9/include/mesos/resources.hpp
 --
 diff --git a/include/mesos/resources.hpp b/include/mesos/resources.hpp
 index 6bfac2e..fe8a574 100644
 --- a/include/mesos/resources.hpp
 +++ b/include/mesos/resources.hpp
 @@ -209,6 +209,8 @@ public:

bool empty() const { return resources.size() == 0; }

 +  size_t size() const { return resources.size(); }
 +
// Checks if this Resources is a superset of the given Resources.
bool contains(const Resources& that) const;



 http://git-wip-us.apache.org/repos/asf/mesos/blob/d9d966d9/include/mesos/v1/resources.hpp
 --
 diff --git a/include/mesos/v1/resources.hpp
 b/include/mesos/v1/resources.hpp
 index 5a88c07..c27927e 100644
 --- a/include/mesos/v1/resources.hpp
 +++ b/include/mesos/v1/resources.hpp
 @@ -209,6 +209,8 @@ public:

bool empty() const { return resources.size() == 0; }

 +  size_t size() const { return resources.size(); }
 +
// Checks if this Resources is a superset of the given Resources.
bool contains(const Resources& that) const;



>>>
>>
>

Re: [RESULT][VOTE] Release Apache Mesos 0.27.0 (rc2)

[Jie Yu]

Niklas,

I think Joris is still working on the user doc for multi-disk support in
Mesos.

- Jie

On Thu, Feb 4, 2016 at 1:22 AM, Niklas Nielsen  wrote:

> Awesome guys!
>
> Kapil, we usually linked to the user documentation in the blog to the new
> features. Do you have a link to the docs on multiple disk resources?
>
> On Wed, Feb 3, 2016 at 11:27 PM, Kapil Arya  wrote:
>
> > And here is the blog post:
> > http://mesos.apache.org/blog/mesos-0-27-0-released.
> >
> > On Wed, Feb 3, 2016 at 4:48 PM, Michael Park  wrote:
> > > Kapil is currently working on it. We'll publish it shortly :)
> > >
> > > On 3 February 2016 at 13:41, Benjamin Mahler 
> wrote:
> > >>
> > >> Great! Is a blog post on the way?
> > >>
> > >> On Sun, Jan 31, 2016 at 5:39 PM, Michael Park 
> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > The vote for Mesos 0.27.0 (rc2) has passed with the
> > >> > following votes.
> > >> >
> > >> > +1 (Binding)
> > >> > --
> > >> > Vinod Kone
> > >> > Joris Van Remoortere
> > >> > Till Toenshoff
> > >> >
> > >> > +1 (Non-binding)
> > >> > --
> > >> > Jörg Schad
> > >> > Marco Massenzio
> > >> > Greg Mann
> > >> >
> > >> > There were no 0 or -1 votes.
> > >> >
> > >> > Please find the release at:
> > >> > https://dist.apache.org/repos/dist/release/mesos/0.27.0
> > >> >
> > >> > It is recommended to use a mirror to download the release:
> > >> > http://www.apache.org/dyn/closer.cgi
> > >> >
> > >> > The CHANGELOG for the release is available at:
> > >> >
> > >> >
> > >> >
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0
> > >> >
> > >> > The mesos-0.27.0.jar has been released to:
> > >> > https://repository.apache.org
> > >> >
> > >> > The website (http://mesos.apache.org) will be updated shortly to
> > reflect
> > >> > this release.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Tim, Kapil, MPark
> > >> >
> > >
> > >
> >
>
>
>
> --
> Niklas
>

Re: [3/3] mesos git commit: Plugged in docker runtime isolator.

[Jie Yu]

Thanks James. Just committed a fix.

On Wed, Feb 3, 2016 at 8:54 PM, James Peach <jor...@gmail.com> wrote:

>
> > On Feb 3, 2016, at 5:45 PM, ji...@apache.org wrote:
> >
> > Plugged in docker runtime isolator.
> >
> > Review: https://reviews.apache.org/r/43036/
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/0b0a3dc5
> > Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/0b0a3dc5
> > Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/0b0a3dc5
> >
> > Branch: refs/heads/master
> > Commit: 0b0a3dc5467224511b1963dd0ac530bca7506376
> > Parents: 2d5d14f
> > Author: Gilbert Song <songzihao1...@gmail.com>
> > Authored: Wed Feb 3 17:14:23 2016 -0800
> > Committer: Jie Yu <yujie@gmail.com>
> > Committed: Wed Feb 3 17:14:23 2016 -0800
> >
> > --
> > src/slave/containerizer/mesos/containerizer.cpp | 12 +++-
> > .../mesos/isolators/docker/runtime.cpp  | 30 ++--
> > 2 files changed, 39 insertions(+), 3 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/0b0a3dc5/src/slave/containerizer/mesos/containerizer.cpp
> > --
> > diff --git a/src/slave/containerizer/mesos/containerizer.cpp
> b/src/slave/containerizer/mesos/containerizer.cpp
> > index 5f8b6c7..12294cd 100644
> > --- a/src/slave/containerizer/mesos/containerizer.cpp
> > +++ b/src/slave/containerizer/mesos/containerizer.cpp
> > @@ -63,6 +63,10 @@
> > #endif
> >
> > #ifdef __linux__
> > +#include "slave/containerizer/mesos/isolators/docker/runtime.hpp"
> > +#endif
> > +
> > +#ifdef __linux__
> > #include "slave/containerizer/mesos/isolators/filesystem/linux.hpp"
> > #endif
> > #include "slave/containerizer/mesos/isolators/filesystem/posix.hpp"
> > @@ -210,6 +214,7 @@ Try<MesosContainerizer*> MesosContainerizer::create(
> > {"cgroups/mem", ::create},
> > {"cgroups/net_cls", ::create},
> > {"cgroups/perf_event", ::create},
> > +{"docker/runtime", ::create},
> > {"namespaces/pid", ::create},
> > #endif
> > #ifdef WITH_NETWORK_ISOLATOR
> > @@ -839,7 +844,12 @@ Future<list<Option>>
> MesosContainerizerProcess::prepare(
> >   }
> >
> >   if (provisionInfo.isSome()) {
> > -containerConfig.set_rootfs(provisionInfo.get().rootfs);
> > +containerConfig.set_rootfs(provisionInfo->rootfs);
> > +
> > +if (provisionInfo->dockerManifest.isSome()) {
> > +  ContainerConfig::Docker* docker =
> containerConfig.mutable_docker();
> > +
> docker->mutable_manifest()->CopyFrom(provisionInfo->dockerManifest.get());
> > +}
> >   }
> >
> >   // We prepare the isolators sequentially according to their ordering
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/0b0a3dc5/src/slave/containerizer/mesos/isolators/docker/runtime.cpp
> > --
> > diff --git a/src/slave/containerizer/mesos/isolators/docker/runtime.cpp
> b/src/slave/containerizer/mesos/isolators/docker/runtime.cpp
> > index f5f9678..5189a6d 100644
> > --- a/src/slave/containerizer/mesos/isolators/docker/runtime.cpp
> > +++ b/src/slave/containerizer/mesos/isolators/docker/runtime.cpp
> > @@ -16,6 +16,10 @@
> >
> > #include 
> >
> > +#include 
> > +
> > +#include 
> > +
> > #include "slave/flags.hpp"
> >
> > #include "slave/containerizer/mesos/isolators/docker/runtime.hpp"
> > @@ -48,7 +52,10 @@
> DockerRuntimeIsolatorProcess::~DockerRuntimeIsolatorProcess() {}
> >
> > Try<Isolator*> DockerRuntimeIsolatorProcess::create(const Flags& flags)
> > {
> > -  return nullptr;
> > +  process::Owned process(
> > +  new DockerRuntimeIsolatorProcess(flags));
> > +
> > +  return new MesosIsolator(process);
> > }
> >
> >
> > @@ -64,7 +71,26 @@ Future<Option>
> DockerRuntimeIsolatorProcess::prepare(
> > const ContainerID& containerId,
> > const ContainerConfig& containerConfig)
> > {
> > -  return None();
> > +  const ExecutorInfo& executorInfo = containerConfig.executor_info();
> > +
> > +  if (!executorInfo.has_container()) {
> > +return None();
> > +  }
> > +
> > +  if (executorInfo.container().type() != ContainerInfo::MESOS) {
> > +return Failure("Can only prepare docker runtime for a MESOS
> contaienr");
>
> s/contaienr/container/
>
> > +  }
> > +
> > +  if (!containerConfig.has_docker()) {
> > +// No docker image default config available.
> > +return None();
> > +  }
> > +
> > +  // Contains docker image default environment variables, merged
> > +  // command, and working directory.
> > +  ContainerLaunchInfo launchInfo;
> > +
> > +  return launchInfo;
> > }
> >
> >
> >
>
>

Re: mesos git commit: Fixed posix filesystem isolator to not allow executors with image.

[Jie Yu]

James, this is for filesystem/posix isolator, and has nothing to do with
posix/disk isolator. Also, this has nothing to do with persistent volumes.

- Jie

On Wed, Jan 6, 2016 at 8:03 PM, James Peach  wrote:

>
> > On Jan 6, 2016, at 7:44 PM, Timothy Chen  wrote:
> >
> > Hi James,
> >
> > There isn't any backward compatibility needed since we never really do
> > anything with volumes with posix filesystem, now we're just making
> > sure we don't allow it since it can cause problems especially with
> > volumes that has images.
>
> But if I had the posix disk isolator enabled and happened to use a volume,
> would my task now fail when it previously did not?
>
> >
> > Tim
> >
> > On Wed, Jan 6, 2016 at 7:26 PM, James Peach  wrote:
> >> Hi Tim,
> >>
> >> What are the backwards compatibility implications of this?
> >>
> >>> On Jan 6, 2016, at 6:50 PM, tnac...@apache.org wrote:
> >>>
> >>> Repository: mesos
> >>> Updated Branches:
> >>> refs/heads/master c258d8af7 -> 52abf8de3
> >>>
> >>>
> >>> Fixed posix filesystem isolator to not allow executors with image.
> >>>
> >>> Review: https://reviews.apache.org/r/41909/
> >>>
> >>>
> >>> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> >>> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/52abf8de
> >>> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/52abf8de
> >>> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/52abf8de
> >>>
> >>> Branch: refs/heads/master
> >>> Commit: 52abf8de380cf7a3c3d8a2e5616b3d34d7b6b277
> >>> Parents: c258d8a
> >>> Author: Timothy Chen 
> >>> Authored: Tue Jan 5 17:29:57 2016 -0800
> >>> Committer: Timothy Chen 
> >>> Committed: Wed Jan 6 18:01:32 2016 -0800
> >>>
> >>> --
> >>> .../containerizer/mesos/isolators/filesystem/posix.cpp  | 9
> +
> >>> 1 file changed, 5 insertions(+), 4 deletions(-)
> >>> --
> >>>
> >>>
> >>>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/52abf8de/src/slave/containerizer/mesos/isolators/filesystem/posix.cpp
> >>> --
> >>> diff --git
> a/src/slave/containerizer/mesos/isolators/filesystem/posix.cpp
> b/src/slave/containerizer/mesos/isolators/filesystem/posix.cpp
> >>> index 00ff84b..4d6100e 100644
> >>> --- a/src/slave/containerizer/mesos/isolators/filesystem/posix.cpp
> >>> +++ b/src/slave/containerizer/mesos/isolators/filesystem/posix.cpp
> >>> @@ -78,17 +78,18 @@ Future
> PosixFilesystemIsolatorProcess::prepare(
> >>>return Failure("Container has already been prepared");
> >>>  }
> >>>
> >>> -  // Return failure if the container change the filesystem root
> >>> -  // because the symlinks will become invalid in the new root.
> >>>  if (executorInfo.has_container()) {
> >>>CHECK_EQ(executorInfo.container().type(), ContainerInfo::MESOS);
> >>>
> >>> +// Return failure if the container change the filesystem root
> >>> +// because the symlinks will become invalid in the new root.
> >>>if (executorInfo.container().mesos().has_image()) {
> >>>  return Failure("Container root filesystems not supported");
> >>>}
> >>>
> >>> -// TODO(jieyu): Also return a failure if there exists images in
> >>> -// the specified volumes.
> >>> +if (executorInfo.container().volumes().size() > 0) {
> >>> +  return Failure("Volumes in ContainerInfo is not supported");
> >>> +}
> >>>  }
> >>>
> >>>  infos.put(containerId, Owned(new Info(directory)));
> >>>
> >>
>
>

Re: `F()` vs `F(void)`

[Jie Yu]

+1

On Sun, Dec 13, 2015 at 10:46 AM, Michael Park  wrote:

> Hello,
>
> In the C++ world, the *void* parameter is considered to be only there for C
> compatibility reasons.
>
> We do a good job of not using *void *parameters in function declarations,
> e.g., *void F();*. On the other hand, we're *not* so good doing so for
> function types, e.g., *std::function*.
>
> I would like to see the codebase converge to *not* use *void* as a
> parameter type, and would like feedback if anyone holds strong opposing
> opinions.
>
> Thanks,
>
> MPark.
>

Re: Fetcher refactor proposal

[Jie Yu]

Thanks guys!

Created an Epic (MESOS-3918
<https://issues.apache.org/jira/browse/MESOS-3918>) to track.

On Wed, Nov 11, 2015 at 2:31 AM, Bernd Mathiske <be...@mesosphere.io> wrote:

> +1 - go for it!
>
> > On Nov 11, 2015, at 12:45 AM, Jie Yu <yujie@gmail.com> wrote:
> >
> > Hi,
> >
> > Fetcher was originally designed to fetch CommandInfo::URIs (e.g.,
> executor
> > binary) for executors/tasks. A recent refactor (MESOS-336
> > <https://issues.apache.org/jira/browse/MESOS-336>) added caching
> support to
> > the fetcher. The recent work on filesystem isolation/unified
> containerizer (
> > MESOS-2840 <https://issues.apache.org/jira/browse/MESOS-2840>) requires
> > Mesos to fetch filesystem images (e.g., APPC/DOCKER images) as well. The
> > natural question is: can we leverage the fetcher to fetch those
> filesystem
> > images (and cache them accordingly)? Unfortunately, the existing fetcher
> > interface is tightly coupled with CommandInfo::URIs for executors/tasks,
> > making it very hard to be re-used to fetch/cache filesystem images.
> >
> > Another motivation for the refactor is that we want to extend the fetcher
> > to support more types of schemes. For instance, we want to support magnet
> > URI to enable p2p fetching. This is in fact quite important for
> operating a
> > large cluster (MESOS-3596 <
> https://issues.apache.org/jira/browse/MESOS-3596>).
> > The goal here is to allow fetcher to be extended (e.g., using modules) so
> > that operators can add custom fetching support.
> >
> > I proposed a solution in this doc
> > <
> https://docs.google.com/document/d/1p8tmQrGtxG6keZVo19gvHPr9WHxeny6PHTVofcLWqco/edit?usp=sharing
> >.
> > The main idea is to decouple artifacts fetching from artifacts cache
> > management. We can make artifacts fetching extensible (e.g. to support
> p2p
> > fetching), and solve the cache management part later.
> >
> > Let me know your thoughts! Thanks!
> >
> > - Jie
>
>

Fetcher refactor proposal

[Jie Yu]

Hi,

Fetcher was originally designed to fetch CommandInfo::URIs (e.g., executor
binary) for executors/tasks. A recent refactor (MESOS-336
) added caching support to
the fetcher. The recent work on filesystem isolation/unified containerizer (
MESOS-2840 ) requires
Mesos to fetch filesystem images (e.g., APPC/DOCKER images) as well. The
natural question is: can we leverage the fetcher to fetch those filesystem
images (and cache them accordingly)? Unfortunately, the existing fetcher
interface is tightly coupled with CommandInfo::URIs for executors/tasks,
making it very hard to be re-used to fetch/cache filesystem images.

Another motivation for the refactor is that we want to extend the fetcher
to support more types of schemes. For instance, we want to support magnet
URI to enable p2p fetching. This is in fact quite important for operating a
large cluster (MESOS-3596 ).
The goal here is to allow fetcher to be extended (e.g., using modules) so
that operators can add custom fetching support.

I proposed a solution in this doc
.
The main idea is to decouple artifacts fetching from artifacts cache
management. We can make artifacts fetching extensible (e.g. to support p2p
fetching), and solve the cache management part later.

Let me know your thoughts! Thanks!

- Jie

Re: Fetcher refactor proposal

[Jie Yu]

Tom, I don't have immediate plan to replace CommandInfo::URI (with
executable/extract bits) with URI (in the doc), at least for now. The
existing Fetcher will still perform extraction, chown, etc. for now
(eventually, though I think those logics should be moved to
slave/containerizer). The existing Fetcher can download the artifacts by
leveraging the new uri::Fetcher interface (need a little refactor).

On Tue, Nov 10, 2015 at 4:44 PM, Tom Arnfeld <t...@duedil.com> wrote:

> This looks like a great change, btw!
>
> I have a quick question, how does this change affect things like the
> executable/extract bits that are available in the existing fetcher? Would
> that logic move outside of the fetcher itself, or would it live on the URI?
>
> I’m not sure if I’ve missed something in the design doc about this, but it
> came to mind…
>
> Tom.
>
> > On 10 Nov 2015, at 23:45, Jie Yu <yujie@gmail.com> wrote:
> >
> > Hi,
> >
> > Fetcher was originally designed to fetch CommandInfo::URIs (e.g.,
> executor
> > binary) for executors/tasks. A recent refactor (MESOS-336
> > <https://issues.apache.org/jira/browse/MESOS-336>) added caching
> support to
> > the fetcher. The recent work on filesystem isolation/unified
> containerizer (
> > MESOS-2840 <https://issues.apache.org/jira/browse/MESOS-2840>) requires
> > Mesos to fetch filesystem images (e.g., APPC/DOCKER images) as well. The
> > natural question is: can we leverage the fetcher to fetch those
> filesystem
> > images (and cache them accordingly)? Unfortunately, the existing fetcher
> > interface is tightly coupled with CommandInfo::URIs for executors/tasks,
> > making it very hard to be re-used to fetch/cache filesystem images.
> >
> > Another motivation for the refactor is that we want to extend the fetcher
> > to support more types of schemes. For instance, we want to support magnet
> > URI to enable p2p fetching. This is in fact quite important for
> operating a
> > large cluster (MESOS-3596 <
> https://issues.apache.org/jira/browse/MESOS-3596>).
> > The goal here is to allow fetcher to be extended (e.g., using modules) so
> > that operators can add custom fetching support.
> >
> > I proposed a solution in this doc
> > <
> https://docs.google.com/document/d/1p8tmQrGtxG6keZVo19gvHPr9WHxeny6PHTVofcLWqco/edit?usp=sharing
> >.
> > The main idea is to decouple artifacts fetching from artifacts cache
> > management. We can make artifacts fetching extensible (e.g. to support
> p2p
> > fetching), and solve the cache management part later.
> >
> > Let me know your thoughts! Thanks!
> >
> > - Jie
>
>

Re: Filesystem isolator test fail

[Jie Yu]

Can you create a ticket with full verbose logging. Which test are you
running? Which version are you using?

Thanks,
- Jie

On Fri, Nov 6, 2015 at 9:27 PM, Vaibhav Khanduja 
wrote:

> On my build setup (using vagrant ubuntu), I am seeing filesystem isolator
> test fail with error message:
>
> E1107 05:24:47.878077   336 slave.cpp:3449] Container
> '9e31b321-bbc7-4914-b8d6-8a14aeb31985' for executor
> '162fa75a-18c5-4424-b0ff-6064279ac1e4' of framework
> cc53bbc7-5075-40ef-a7b3-074da8a269be- failed to start: *None of the
> enabled containerizers (mesos) could create a container for the provided
> TaskInfo/ExecutorInfo message*
>
> Any hint why it may be happening?
>
> Thanks
>

Re: Welcome Kapil as Mesos committer and PMC member!

[Jie Yu]

Congrats Kapil!

On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff  wrote:

> I'm happy to announce that Kapil Arya has been voted a Mesos committer and
> PMC member!
>
> Welcome Kapil, and thanks for all of your great contributions to the
> project so far!
>
> Looking forward to lots more of your contributions!
>
> Thanks
> Till

Re: Apache Mesos Community Sync

[Jie Yu]

Adam, since most of the Twitter folks are OOO this week. I chatted with
Artem/Vinod. we think it makes sense to host the sync at Mesosphere
tomorrow.

- Jie

On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon  wrote:

> It's been a while since our last community sync, and tomorrow, Thursday
> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting, since
> those have traditionally been "Monthly on the first Thursday". After
> this, the other meetings (third Thursday, or every other week?) can
> alternate between 9pm/9am. Let's get these on the calendar officially.
>
> Vinod, are you/Twitter still planning to host the community sync tomorrow?
>
> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon  wrote:
>
>> We'll have the next community sync this Thursday (Oct. 15th) from 9-10am
>> Pacific.
>>
>> Please add items to the agenda
>> 
>> .
>>
>>
>> We will use Hangouts on Air again. We will post the video stream link
>> shortly before the meeting, and only active participants (especially people
>> on the agenda) should join the actual hangout. Others can watch the video
>> stream and ask brief questions on #mesos on IRC. If you have something
>> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
>> into the hangout.
>>
>> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
>> reception on the 2nd floor.
>>
>>
>> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>>
>>> Got it. Thank you.
>>>
>>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>>> wrote:
>>>
>>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is
>>> still not
>>> > available. And here is the link for meeting agenda/notes:
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>> >
>>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>>> >
>>> > > Do today have community sync?
>>> > >
>>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon 
>>> > > wrote:
>>> > >
>>> > > > Today's community sync video/audio is archived at:
>>> > > > http://youtu.be/ZQT6-fw8Ito
>>> > > > The meeting agenda/notes are available at:
>>> > > >
>>> > > >
>>> > >
>>> >
>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>> > > >
>>> > > > For convenience, today's notes are reproduced below:
>>> > > >
>>> > > >-
>>> > > >
>>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>>> > > >-
>>> > > >
>>> > > >   What’s the plan for how many releases we want to support?
>>> BenH:
>>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x) for
>>> > > > which we will
>>> > > >   do patch fixes
>>> > > >   Neil: Or support an LTS version + recent releases
>>> > > >   -
>>> > > >
>>> > > >   Separate Release Manager for backports? Joris and MPark will
>>> RM
>>> > for
>>> > > >   these patch releases, with Adam shepherding. In general,
>>> > > patch/point
>>> > > >   releases don’t need to be managed by the same person who did
>>> the
>>> > > > original
>>> > > >   release.
>>> > > >   -
>>> > > >
>>> > > >   Need some guidelines (on the website) for what is a
>>> > > >   backport-able/critical patch.
>>> > > >   -
>>> > > >
>>> > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
>>> releases,
>>> > > >   guidelines for critical patches, RM roles/responsibilities
>>> > > >   -
>>> > > >
>>> > > >0.25.0 Release Planning[Joris]: Dashboard
>>> > > ><
>>> > > >
>>> > >
>>> >
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
>>> > > > >
>>> > > >-
>>> > > >
>>> > > >   Planning a triage meeting for Friday, hope to cut 0.25.0-rc1
>>> by
>>> > > Sept.
>>> > > >   23rd.
>>> > > >   -
>>> > > >
>>> > > >MesosCon EU [Adam]: Schedule announced!
>>> > > > http://mesosconeu2015.sched.org/
>>> > > >-
>>> > > >
>>> > > >   Register! Attend! Meet cool people! Learn awesome things!
>>> > > >   -
>>> > > >
>>> > > >   Want to grow developer community as well as user community
>>> > > >   -
>>> > > >
>>> > > >   Community voting vs. Program Committee selection?
>>> > > >   -
>>> > > >
>>> > > >Mesos Developer Community Sync Frequency to weekly [Joris, BenH]
>>> > > >-
>>> > > >
>>> > > >   Rotating time for time zones
>>> > > >   -
>>> > > >
>>> > > >   Weeklys can be video/hangout
>>> > > >   -
>>> > > >
>>> > > >   1/mo can be on-site @Twitter/Mesosphere/etc
>>> > > >   -
>>> > > >
>>> > > >   AI [Joris]: Send out email proposal for times, weekly
>>> schedule
>>> > > >   -
>>> > > >
>>> > > >   Proposal: Send each meeting’s notes to dev list (in plain
>>> text)
>>> > > >   afterwards
>>> > > >   -

Re: Removing external containerizer from code base

[Jie Yu]

FYI, I created this ticket to track
https://issues.apache.org/jira/browse/MESOS-3709

Kapil, do you want to pick this up? I can pick this up as well once I
finish a few stuff on my hand.

On Mon, Oct 12, 2015 at 12:50 AM, Timothy Chen <tnac...@gmail.com> wrote:

> Yes it can be a module.
>
> Tim
>
> On Mon, Oct 12, 2015 at 12:04 AM, tommy xiao <xia...@gmail.com> wrote:
> > HI Jie Yu,
> >
> > https://issues.apache.org/jira/browse/MESOS-3435 in this proposal, i
> sure
> > the hyper is new containerizer, Does this can implement as a module?
> >
> > 2015-10-08 8:12 GMT+08:00 Jie Yu <yujie@gmail.com>:
> >
> >> Hey guys,
> >>
> >> Per discussion in MESOS-3370
> >> <https://issues.apache.org/jira/browse/MESOS-3370>, I'll start removing
> >> the
> >> external containerizer and cleaning up the relevant code.
> >>
> >> Please let me know if you have any concern. Thanks!
> >>
> >> - Jie
> >>
> >
> >
> >
> > --
> > Deshi Xiao
> > Twitter: xds2000
> > E-mail: xiaods(AT)gmail.com
>

Re: Removing external containerizer from code base

[Jie Yu]

Alex,

Implementing your own containerizer totally makes sense. The containerizer
interface can be modulized and your own containerizer can be implemented as
a module. Please take a look at the module documentation
<https://github.com/apache/mesos/blob/master/docs/modules.md>. From what I
can tell, implementing your own containerizer as a module will definitely
be simpler than an external solution.

 I assume we would have to implement it in cpp,


Most likely because that's the most straightforward way. Other languages
are also possible (e.g., using JNI for Java).

it might require recompiling (parts of) Mesos, some other things?


No. With modules, you don't have to.

Let me know if you have any further questions!

- Jie

On Thu, Oct 8, 2015 at 10:44 AM, Alex Glikson <glik...@il.ibm.com> wrote:

> Actually we have been thinking to implement our own containerizer, and the
> option to use ECP seemed attractive.
> Can you, please, elaborate on the implications of having our own
> containerizer without ECP? I assume we would have to implement it in cpp,
> it might require recompiling (parts of) Mesos, some other things?
>
> Thanks,
> Alex
>
>
>
>
> From:Jie Yu <yujie@gmail.com>
> To:mesos <dev@mesos.apache.org>, "u...@mesos.apache.org" <
> u...@mesos.apache.org>
> Date:08/10/2015 03:12 AM
> Subject:Removing external containerizer from code base
> --
>
>
>
> Hey guys,
>
> Per discussion in MESOS-3370
> <https://issues.apache.org/jira/browse/MESOS-3370>, I'll start removing
> the
> external containerizer and cleaning up the relevant code.
>
> Please let me know if you have any concern. Thanks!
>
> - Jie
>
>
>

Re: Removing external containerizer from code base

[Jie Yu]

Alex,

but I don't see 'containerizer' as one of the supported module types listed
> in the documentation.. Can you, please, clarify?


Not right now, but should be very trivial to do. Kapil or I can definitely
help with this.

- Jie

On Thu, Oct 8, 2015 at 11:15 AM, Alex Glikson <glik...@il.ibm.com> wrote:

> Thanks Jie, this sounds promising, but I don't see 'containerizer' as one
> of the supported module types listed in the documentation..
> Can you, please, clarify?
>
> Thanks,
> Alex
>
>
>
>
> From:   Jie Yu <yujie@gmail.com>
> To: u...@mesos.apache.org
> Cc: dev <dev@mesos.apache.org>
> Date:   08/10/2015 08:57 PM
> Subject:Re: Removing external containerizer from code base
>
>
>
> Alex,
>
> Implementing your own containerizer totally makes sense. The containerizer
> interface can be modulized and your own containerizer can be implemented
> as
> a module. Please take a look at the module documentation
> <https://github.com/apache/mesos/blob/master/docs/modules.md>. From what I
> can tell, implementing your own containerizer as a module will definitely
> be simpler than an external solution.
>
>  I assume we would have to implement it in cpp,
>
>
> Most likely because that's the most straightforward way. Other languages
> are also possible (e.g., using JNI for Java).
>
> it might require recompiling (parts of) Mesos, some other things?
>
>
> No. With modules, you don't have to.
>
> Let me know if you have any further questions!
>
> - Jie
>
> On Thu, Oct 8, 2015 at 10:44 AM, Alex Glikson <glik...@il.ibm.com> wrote:
>
> > Actually we have been thinking to implement our own containerizer, and
> the
> > option to use ECP seemed attractive.
> > Can you, please, elaborate on the implications of having our own
> > containerizer without ECP? I assume we would have to implement it in
> cpp,
> > it might require recompiling (parts of) Mesos, some other things?
> >
> > Thanks,
> > Alex
> >
> >
> >
> >
> > From:Jie Yu <yujie@gmail.com>
> > To:mesos <dev@mesos.apache.org>, "u...@mesos.apache.org" <
> > u...@mesos.apache.org>
> > Date:08/10/2015 03:12 AM
> > Subject:Removing external containerizer from code base
> > --
> >
> >
> >
> > Hey guys,
> >
> > Per discussion in MESOS-3370
> > <https://issues.apache.org/jira/browse/MESOS-3370>, I'll start removing
> > the
> > external containerizer and cleaning up the relevant code.
> >
> > Please let me know if you have any concern. Thanks!
> >
> > - Jie
> >
> >
> >
>
>
>
>

Removing external containerizer from code base

[Jie Yu]

Hey guys,

Per discussion in MESOS-3370
, I'll start removing the
external containerizer and cleaning up the relevant code.

Please let me know if you have any concern. Thanks!

- Jie

Re: [jira] [Created] (MESOS-3498) Failed to create a containerizer

[Jie Yu]

+ Kapil

On Tue, Sep 22, 2015 at 5:59 PM, Rafael Capucho (JIRA) 
wrote:

> Rafael Capucho created MESOS-3498:
> -
>
>  Summary: Failed to create a containerizer
>  Key: MESOS-3498
>  URL: https://issues.apache.org/jira/browse/MESOS-3498
>  Project: Mesos
>   Issue Type: Bug
>   Components: docker
> Affects Versions: 0.25.0
>  Environment: Docker 1.8.2
> Ubuntu 14.04.1 LTS
> User: root
> Linux li202-122 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015
> x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Rafael Capucho
>
>
> I'm using that script to compile mesos[1] and it's working properly, i can
> deploy mesos master ok.
>
> [1] -
> https://bitbucket.org/rafaelcapucho/docker-mesos-master/src/b8709d3cbe52255f8eb5df17f79abff6b1945e95/Dockerfile?at=master=file-view-default
>
> The problem is when I will deploy mesos slave with the same [1] script,
> running:
>
> docker run rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
>
> It exit after couple of seconds, the log:
>
> root@li202-122:~# docker run -e "MESOS_LOG_DIR=/var/log/mesos"
> rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
> I0923 00:28:11.621003 1 logging.cpp:172] INFO level logging started!
> I0923 00:28:11.621363 1 main.cpp:185] Build: 2015-09-22 23:39:14 by
> I0923 00:28:11.621389 1 main.cpp:187] Version: 0.25.0
> I0923 00:28:11.621397 1 main.cpp:194] Git SHA:
> f5ec1d006794ef906e8b56861aa771888a73702f
> I0923 00:28:11.622469 1 containerizer.cpp:143] Using isolation:
> posix/cpu,posix/mem,filesystem/posix
> Failed to create a containerizer: Could not create MesosContainerizer:
> Failed to create launcher: Failed to create Linux launcher: Failed to
> create root cgroup /sys/fs/cgroup/freezer/mesos: Failed to create directory
> '/sys/fs/cgroup/freezer/mesos': Read-only file system
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: [5/5] mesos git commit: Integer Precision for JSON <-> Protobuf conversions.

[Jie Yu]

Joris,

It breaks the build:

picojson-1.3.0/picojson.h: In member function ‘std::string
picojson::value::to_str() const’:
picojson-1.3.0/picojson.h:370:38: error: expected ‘)’ before ‘PRId64’
   SNPRINTF(buf, sizeof(buf), "%" PRId64, u_.int64_);



On Wed, Sep 16, 2015 at 2:56 PM,  wrote:

> Integer Precision for JSON <-> Protobuf conversions.
>
> * Add TODO's for refactoring some JSON parsing in the docker code
>   (See MESOS-3409).  Update how the JSON::Number is used.
> * Tweak some tests to match changes to JSON::Number.
> * Address a TODO on one test, which used a workaround for
>   double-precision comparison.
>
> Review: https://reviews.apache.org/r/38077
>
>
> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/2c277f1c
> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/2c277f1c
> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/2c277f1c
>
> Branch: refs/heads/master
> Commit: 2c277f1c0e0dc0a6618ba930bb5f8d9dd753d4be
> Parents: df9eacb
> Author: Joseph Wu 
> Authored: Wed Sep 16 13:44:47 2015 -0400
> Committer: Joris Van Remoortere 
> Committed: Wed Sep 16 17:48:43 2015 -0400
>
> --
>  src/docker/docker.cpp   |   3 +-
>  .../provisioners/docker/token_manager.cpp   |   3 +-
>  src/tests/fault_tolerance_tests.cpp |   2 +-
>  src/tests/master_tests.cpp  |   2 +-
>  src/tests/monitor_tests.cpp |  50 +++--
>  src/tests/rate_limiting_tests.cpp   | 106 +--
>  src/tests/slave_tests.cpp   |   2 +-
>  7 files changed, 93 insertions(+), 75 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2c277f1c/src/docker/docker.cpp
> --
> diff --git a/src/docker/docker.cpp b/src/docker/docker.cpp
> index c4c37cb..afcedf1 100755
> --- a/src/docker/docker.cpp
> +++ b/src/docker/docker.cpp
> @@ -236,6 +236,7 @@ Try Docker::validateVersion(const Version&
> minVersion) const
>  }
>
>
> +// TODO(josephw): Parse this string with a protobuf.
>  Try Docker::Container::create(const string& output)
>  {
>Try parse = JSON::parse(output);
> @@ -286,7 +287,7 @@ Try Docker::Container::create(const
> string& output)
>  return Error("Error finding Pid in State: " + pidValue.error());
>}
>
> -  pid_t pid = pid_t(pidValue.get().value);
> +  pid_t pid = pid_t(pidValue.get().as());
>
>Option optionalPid;
>if (pid != 0) {
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2c277f1c/src/slave/containerizer/provisioners/docker/token_manager.cpp
> --
> diff --git a/src/slave/containerizer/provisioners/docker/token_manager.cpp
> b/src/slave/containerizer/provisioners/docker/token_manager.cpp
> index aec915f..95f459d 100644
> --- a/src/slave/containerizer/provisioners/docker/token_manager.cpp
> +++ b/src/slave/containerizer/provisioners/docker/token_manager.cpp
> @@ -122,6 +122,7 @@ Token::Token(
>  notBefore(_notBefore) {}
>
>
> +// TODO(josephw): Parse this string with some protobufs.
>  Try Token::create(const string& raw)
>  {
>auto decode = [](
> @@ -196,7 +197,7 @@ Result Token::getTimeValue(const JSON::Object&
> object, const string& key)
>
>// If expiration is provided, we will process it for future validations.
>if (jsonValue.isSome()) {
> -Try time = Time::create(jsonValue.get().value);
> +Try time = Time::create(jsonValue.get().as());
>  if (time.isError()) {
>return Error("Failed to decode time: " + time.error());
>  }
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2c277f1c/src/tests/fault_tolerance_tests.cpp
> --
> diff --git a/src/tests/fault_tolerance_tests.cpp
> b/src/tests/fault_tolerance_tests.cpp
> index 061e099..c97bc46 100644
> --- a/src/tests/fault_tolerance_tests.cpp
> +++ b/src/tests/fault_tolerance_tests.cpp
> @@ -1918,7 +1918,7 @@ TEST_F(FaultToleranceTest,
> UpdateFrameworkInfoOnSchedulerFailover)
>EXPECT_EQ(1u, framework.values.count("failover_timeout"));
>JSON::Number failoverTimeout =
>  framework.values["failover_timeout"].as();
> -  EXPECT_EQ(finfo2.failover_timeout(), failoverTimeout.value);
> +  EXPECT_EQ(finfo2.failover_timeout(), failoverTimeout.as());
>
>EXPECT_EQ(1u, framework.values.count("hostname"));
>JSON::String hostname = framework.values["hostname"].as();
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/2c277f1c/src/tests/master_tests.cpp
> --
> diff --git a/src/tests/master_tests.cpp 

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

[Jie Yu]

Niklas,

This is the known problem reported by Marco. I am OK with both because the
linux filesystem isolator cannot be used in 0.24.0.

If you guys prefer to cut another RC, here is the patch that needs to be
cherry picked:

commit 3ecd54320397c3a813d555f291b51778372e273b
Author: Greg Mann g...@mesosphere.io
Date:   Fri Aug 21 13:21:10 2015 -0700

Added symlink test for /bin, lib, and /lib64 when preparing test root
filesystem.

Review: https://reviews.apache.org/r/37684



On Thu, Aug 27, 2015 at 3:30 PM, Niklas Nielsen nik...@mesosphere.io
wrote:

 -1: sudo make check on centos 7

 [--] Global test environment tear-down

 [==] 793 tests from 121 test cases ran. (606946 ms total)

 [  PASSED  ] 786 tests.

 [  FAILED  ] 7 tests, listed below:

 [  FAILED  ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup, where
 TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess

 [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem

 [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_VolumeFromSandbox

 [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_VolumeFromHost

 [  FAILED  ]
 LinuxFilesystemIsolatorTest.ROOT_VolumeFromHostSandboxMountPoint

 [  FAILED  ]
 LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithRootFilesystem

 [  FAILED  ] MesosContainerizerLaunchTest.ROOT_ChangeRootfs

 Configured with:

 ../mesos/configure --prefix=/home/vagrant/releases/0.24.0/ --disable-python

 On 26 August 2015 at 17:00, Khanduja, Vaibhav vaibhav.khand...@emc.com
 wrote:

 +1

  On Aug 26, 2015, at 4:43 PM, Vinod Kone vinodk...@gmail.com wrote:
 
  Pinging the thread for more (binding) votes. Hopefully people have
 caught
  up with emails after Mesos madness.
 
  On Wed, Aug 19, 2015 at 1:28 AM, haosdent haosd...@gmail.com wrote:
 
  +1
 
  OS: Ubutnu 14.04
  Verify command: sudo make -j8 check
  Compiler: Both gcc4.8 and clang3.5
  Configuration: default configuration
  Result: all tests(828 tests) pass
 
  MESOS-3053 https://issues.apache.org/jira/browse/MESOS-3053 is
 because
  need update add iptable first.
 
  On Wed, Aug 19, 2015 at 2:39 PM, haosdent haosd...@gmail.com wrote:
 
  Could not
  pass DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged in
 Ubuntu
  14.04. Already have a issue for this
  https://issues.apache.org/jira/browse/MESOS-3053, it is acceptable?
 
  On Wed, Aug 19, 2015 at 12:55 PM, Marco Massenzio 
 ma...@mesosphere.io
  wrote:
 
  +1 (non-binding)
 
  All tests (including ROOT) pass on:
  Ubuntu 14.04 (physical box)
 
  All non-ROOT tests pass on:
  CentOS 7 (VirtualBox VM)
 
  Known issue (MESOS-3050) for ROOT tests on CentOS 7, non-blocker.
 
  Thanks,
 
  *Marco Massenzio*
 
  *Distributed Systems Engineerhttp://codetrips.com 
 http://codetrips.com*
 
  On Tue, Aug 18, 2015 at 3:26 PM, Vinod Kone vinodk...@apache.org
  wrote:
 
  0.24.0 includes the following:
 
 
 
 
 
  Experimental support for v1 scheduler HTTP API!
 
  This release also wraps up support for fetcher.
 
 
  The CHANGELOG for the release is available at:
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.0-rc1
 
 
 
 
 
 
  The candidate for Mesos 0.24.0 release is available at:
 
 
 
 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz
 
 
  The tag to be voted on is 0.24.0-rc1:
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.0-rc1
 
 
  The MD5 checksum of the tarball can be found at:
 
 
 
 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz.md5
 
 
  The signature of the tarball can be found at:
 
 
 
 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz.asc
 
 
  The PGP key used to sign the release is here:
 
  https://dist.apache.org/repos/dist/release/mesos/KEYS
 
 
  The JAR is up in Maven in a staging repository here:
 
 
 https://repository.apache.org/content/repositories/orgapachemesos-1064
 
 
  Please vote on releasing this package as Apache Mesos 0.24.0!
 
 
  The vote is open until Fri Aug 21 15:24:05 PDT 2015 and passes if a
  majority of at least 3 +1 PMC votes are cast.
 
 
  [ ] +1 Release this package as Apache Mesos 0.24.0
 
  [ ] -1 Do not release this package because ...
 
 
  Thanks,
 
  Vinod
 
 
  --
  Best Regards,
  Haosdent Huang
 
 
 
  --
  Best Regards,
  Haosdent Huang
 

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

[Jie Yu]

Tim, maybe just remove CgroupsCpushareIsolatorProcess
from CgroupsIsolatorTypes and add a TODO there for this release?

We can definitely work around it (like you said).

- Jie

On Thu, Aug 27, 2015 at 4:05 PM, Timothy Chen tnac...@gmail.com wrote:

 That test is failing because of a wierd bug in CentOS 7 not naming the
 cgroups correctly (or at least not following the pattern every other
 OS).

 I filed a CentOS bug but no response so far, if we want to fix it we
 will have to work around this problem by hardcoding another cgroup
 name to test cpuacct,cpu.

 Tim

 On Thu, Aug 27, 2015 at 4:00 PM, Vinod Kone vinodk...@apache.org wrote:
  Happy to cut another RC.
 
  IIUC, https://reviews.apache.org/r/37684 doesn't fix the below test.
 
  [  FAILED  ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup, where
  TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess
 
  Is someone working on fixing that (MESOS-3294
  https://issues.apache.org/jira/browse/MESOS-3294)? If yes, I would
 wait a
  day or two to get that in.
 
  Any other issues people have encountered with RC1?
 
 
 
  On Thu, Aug 27, 2015 at 3:45 PM, Niklas Nielsen nik...@mesosphere.io
  wrote:
 
  If it is that easy to fix, why not get it in?
 
  How about https://issues.apache.org/jira/browse/MESOS-3053 (which
  Haosdent ran into)?
 
  On 27 August 2015 at 15:36, Jie Yu yujie@gmail.com wrote:
 
  Niklas,
 
  This is the known problem reported by Marco. I am OK with both because
  the linux filesystem isolator cannot be used in 0.24.0.
 
  If you guys prefer to cut another RC, here is the patch that needs to
 be
  cherry picked:
 
  commit 3ecd54320397c3a813d555f291b51778372e273b
  Author: Greg Mann g...@mesosphere.io
  Date:   Fri Aug 21 13:21:10 2015 -0700
 
  Added symlink test for /bin, lib, and /lib64 when preparing test
 root
  filesystem.
 
  Review: https://reviews.apache.org/r/37684
 
 
 
  On Thu, Aug 27, 2015 at 3:30 PM, Niklas Nielsen nik...@mesosphere.io
  wrote:
 
  -1: sudo make check on centos 7
 
  [--] Global test environment tear-down
 
  [==] 793 tests from 121 test cases ran. (606946 ms total)
 
  [  PASSED  ] 786 tests.
 
  [  FAILED  ] 7 tests, listed below:
 
  [  FAILED  ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup, where
  TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess
 
  [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem
 
  [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_VolumeFromSandbox
 
  [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_VolumeFromHost
 
  [  FAILED  ]
  LinuxFilesystemIsolatorTest.ROOT_VolumeFromHostSandboxMountPoint
 
  [  FAILED  ]
  LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithRootFilesystem
 
  [  FAILED  ] MesosContainerizerLaunchTest.ROOT_ChangeRootfs
 
  Configured with:
 
  ../mesos/configure --prefix=/home/vagrant/releases/0.24.0/
  --disable-python
 
  On 26 August 2015 at 17:00, Khanduja, Vaibhav 
 vaibhav.khand...@emc.com
  wrote:
 
  +1
 
   On Aug 26, 2015, at 4:43 PM, Vinod Kone vinodk...@gmail.com
 wrote:
  
   Pinging the thread for more (binding) votes. Hopefully people have
  caught
   up with emails after Mesos madness.
  
   On Wed, Aug 19, 2015 at 1:28 AM, haosdent haosd...@gmail.com
  wrote:
  
   +1
  
   OS: Ubutnu 14.04
   Verify command: sudo make -j8 check
   Compiler: Both gcc4.8 and clang3.5
   Configuration: default configuration
   Result: all tests(828 tests) pass
  
   MESOS-3053 https://issues.apache.org/jira/browse/MESOS-3053 is
  because
   need update add iptable first.
  
   On Wed, Aug 19, 2015 at 2:39 PM, haosdent haosd...@gmail.com
  wrote:
  
   Could not
   pass DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged
 in
  Ubuntu
   14.04. Already have a issue for this
   https://issues.apache.org/jira/browse/MESOS-3053, it is
 acceptable?
  
   On Wed, Aug 19, 2015 at 12:55 PM, Marco Massenzio 
  ma...@mesosphere.io
   wrote:
  
   +1 (non-binding)
  
   All tests (including ROOT) pass on:
   Ubuntu 14.04 (physical box)
  
   All non-ROOT tests pass on:
   CentOS 7 (VirtualBox VM)
  
   Known issue (MESOS-3050) for ROOT tests on CentOS 7,
 non-blocker.
  
   Thanks,
  
   *Marco Massenzio*
  
   *Distributed Systems Engineerhttp://codetrips.com 
  http://codetrips.com*
  
   On Tue, Aug 18, 2015 at 3:26 PM, Vinod Kone 
 vinodk...@apache.org
   wrote:
  
   0.24.0 includes the following:
  
  
  
 
 
  
   Experimental support for v1 scheduler HTTP API!
  
   This release also wraps up support for fetcher.
  
  
   The CHANGELOG for the release is available at:
  
  
  
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.0-rc1
  
  
  
 
 
  
  
   The candidate for Mesos 0.24.0 release is available at:
  
  
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1

Re: Mesos Developer Community Design Discussions

[Jie Yu]

Periscope?

On Mon, Aug 10, 2015 at 4:41 PM, Timothy Anderegg 
timothy.ander...@gmail.com wrote:

 Live stream for folks who won't be there would be great, thanks!

 Tim

 On Mon, Aug 10, 2015 at 7:09 PM, Benjamin Hindman b...@eecs.berkeley.edu
 wrote:

  The spreadsheet has been updated, sorry about that!
 
  Dave: we didn't want to pull people away from the hackathon and all the
  other times were taken, so we figured we'd do the best we can! Enough
  people have chatted with me about talking about future features that it
  made sense to put something together for anyone in the community to join.
  We'll try and get live streaming set up for folks that aren't flying in
  until Wednesday (or at all).
 
  On Mon, Aug 10, 2015 at 3:01 PM Dave Lester d...@davelester.org wrote:
 
   Hi Ben,
  
   It looks like the spreadsheet/google form isn't public outside your
   organization, you may need to revise the permissions.
  
   I'm curious, why this particular day? It's a bit unfortunate that only
 8
   day notice is being given, since I imagine most people have their
   flights for MesosCon already booked and will not likely be in
   attendance.
  
   Best,
   Dave
  
   On Mon, Aug 10, 2015, at 02:52 PM, Benjamin Hindman wrote:
We've had great developer community meetings over Google Hangouts,
 but
MesosCon is right around the corner and we'd like to do it in person!
   
I'd like to invite everyone to attend an in person developer
 community
meeting on Tuesday, August 18th in Seattle. The focus will be for
 Mesos
committers and contributors to get together to discuss big ticket
features to work on during the next 6 to 12 months. I will be joining
many
other committers at this event and we all look forward to discussing
  new
features with everyone!
   
There is a limited amount of space so please submit your RSVP here:
http://bit.ly/mesosdesignsummit
   
We look forward to seeing you in Seattle! And don't forget to
 register
for
MesosCon
http://events.linuxfoundation.org/events/mesoscon/attend/register
 if
you haven't already!
  
 

Re: Resource Estimator

[Jie Yu]

Tiago,

ResourceEstimator is used for oversubscription and is irrelevant (
https://github.com/apache/mesos/blob/master/docs/oversubscription.md)

The logic of estimating available resources on a slave is here:
https://github.com/apache/mesos/blob/master/src/slave/containerizer/containerizer.cpp#L61

- Jie

On Tue, Jul 21, 2015 at 1:37 PM, Tiago Alves tiagoalve...@gmail.com wrote:

 Hi,

 I would like to know how mesos estimates the available resources
 (CPU/RAM/DISK) of a slave, and how this resources are viewed by the master
 (zookeeper ?)

 I have looked in:

 https://github.com/apache/mesos/blob/master/src/slave/resource_estimator.cpp

 https://github.com/apache/mesos/blob/master/src/slave/resource_estimators/*.cpp

 Can someone give a overview or point the direction of how mesos measures
 the resources ?

 Thank you,
 Tiago Alves

Re: [DISCUSS] Renaming Mesos Slave

[Jie Yu]

Adam,

If a vote is called out, how do we decide if it passes or not. Will that be
the same of voting for a release (i.e., PMC member can veto it)?

I would imagine that some PMC members might want to express some negative
feedbacks on this, but certainly do not want to veto it. How do we deal
with this situation?

As already pointed out in the thread, this name change requires large
amount of work on changing the internal config files, monitoring stack and
a complicated rolling out procedure.

Because of that, I would like to propose that we also *count votes by
organization* and take that into account. We probably don't want to pass a
vote if a majority of the organizations do not want it, right? We'll decide
each organization's +1/-1 by looking at votes from their employees (e.g.,
by majority).

If one does not have an organization associated with, his/her vote will be
put into a separate pool. If an organization wants to stay anonymous, just
use a label (but make sure to use the same label if there are multiple
votes from the same organization).

How does that sound?

- Jie



On Mon, Jun 1, 2015 at 2:18 PM, Adam Bordelon a...@mesosphere.io wrote:

 There has been much discussion about finding a less offensive name than
 Slave, and many of these thoughts have been captured in
 https://issues.apache.org/jira/browse/MESOS-1478

 I would like to open up the discussion on this topic for one week, and if
 we cannot arrive at a lazy consensus, I will draft a proposal from the
 discussion and call for a VOTE.
 Here are the questions I would like us to answer:
 1. What should we call the Mesos Slave node/host/machine?
 2. What should we call the mesos-slave process (could be the same)?
 3. Do we need to rename Mesos Master too?

 Another topic worth discussing is the deprecation process, but we don't
 necessarily need to decide on that at the same time as deciding the new
 name(s).
 4. How will we phase in the new name and phase out the old name?

 Please voice your thoughts and opinions below.

 Thanks!
 -Adam-

 P.S. My personal thoughts:
 1. Mesos Worker [Node]
 2. Mesos Worker or Agent
 3. No
 4. Carefully

Re: [DISCUSS] Renaming Mesos Slave

[Jie Yu]

Dave,

I am not saying that we should make the decision solely based on
organization votes. This is just an extra input we can use while making the
decision.

By looking at the threads, looks like we don't have a community consensus
here. Then the question is: how do we make a *better* decision without a
community consensus.

I would like get inputs from organization's perspective because I believe
the order of complexities of changing the internal config/monitoring stack
within organizations are the same regardless of their sizes. So gathering
inputs from that perspective should be helpful for us to make a better
decision.

- Jie

On Wed, Jun 3, 2015 at 8:57 AM, Dave Lester d...@davelester.org wrote:

 Hi Jie,

 I understand your concern here, but within Apache projects,
 organizations do not have a voice/vote -- people do.

 I think should take into strong consideration the overhead any change
 may have on any adopter/organization and discuss those risks and
 problems openly, but ideally this decision would be made based upon
 consensus within the community. If consensus cannot be reached, a vote
 among committers may be necessary.

 Dave

 On Wed, Jun 3, 2015, at 08:52 AM, Jie Yu wrote:
  Adam,
 
  If a vote is called out, how do we decide if it passes or not. Will that
  be
  the same of voting for a release (i.e., PMC member can veto it)?
 
  I would imagine that some PMC members might want to express some negative
  feedbacks on this, but certainly do not want to veto it. How do we deal
  with this situation?
 
  As already pointed out in the thread, this name change requires large
  amount of work on changing the internal config files, monitoring stack
  and
  a complicated rolling out procedure.
 
  Because of that, I would like to propose that we also *count votes by
  organization* and take that into account. We probably don't want to pass
  a
  vote if a majority of the organizations do not want it, right? We'll
  decide
  each organization's +1/-1 by looking at votes from their employees (e.g.,
  by majority).
 
  If one does not have an organization associated with, his/her vote will
  be
  put into a separate pool. If an organization wants to stay anonymous,
  just
  use a label (but make sure to use the same label if there are multiple
  votes from the same organization).
 
  How does that sound?
 
  - Jie
 
 
 
  On Mon, Jun 1, 2015 at 2:18 PM, Adam Bordelon a...@mesosphere.io
 wrote:
 
   There has been much discussion about finding a less offensive name than
   Slave, and many of these thoughts have been captured in
   https://issues.apache.org/jira/browse/MESOS-1478
  
   I would like to open up the discussion on this topic for one week, and
 if
   we cannot arrive at a lazy consensus, I will draft a proposal from the
   discussion and call for a VOTE.
   Here are the questions I would like us to answer:
   1. What should we call the Mesos Slave node/host/machine?
   2. What should we call the mesos-slave process (could be the same)?
   3. Do we need to rename Mesos Master too?
  
   Another topic worth discussing is the deprecation process, but we don't
   necessarily need to decide on that at the same time as deciding the new
   name(s).
   4. How will we phase in the new name and phase out the old name?
  
   Please voice your thoughts and opinions below.
  
   Thanks!
   -Adam-
  
   P.S. My personal thoughts:
   1. Mesos Worker [Node]
   2. Mesos Worker or Agent
   3. No
   4. Carefully
  

Please update your customized reviewboardrc

[Jie Yu]

Hi,

I recently modified the post-reviews.py script so that we can configure the
tracking branch when posting reviews. I also moved a few hard coded
constants (e.g., REPOSITORY_URL) to reviewboardrc so that they are
configurable too.

If you are not using a customized reviewboardrc (i.e., relying on the
default reviewboardrc under support/), please ignore this email.

If you are using a customized reviewboardrc, please add the following to
your reviewboardrc:
REPOSITORY_URL = git://git.apache.org/mesos.git

Thanks!
- Jie

Re: Enabling 'network' namespace for custom network isolators

[Jie Yu]

 Yes. The simplest (cleanest?) way that I see would be to refactor the
 launcher to take the desired flags when executing the executor, i.e.,
 (Linux)Launcher::fork() takes the namespace flags. The launcher would be
 directed which namespaces to create by the caller, not inferring them
 itself from any flags: the MesosContainerizer in turn would determine this
 based on the isolators it was using for the container (querying them). This
 also facilitates the MesosContainerizer having different isolators, and
 thus namespaces, for different containers.


+1

For instance, the isolator could have an interface 'int namespaces()' which
specifies the namespaces needed. The launcher can just query that and pass
them to the linux launcher.

Since currently, the launcher and isolator interfaces are designed for both
mac and linux and namespace does not make sense on Mac, we probably need a
LinuxIsolator interface (inherit from Isolator) and a LinuxLauncher
interface (inherit from Launcher).

- Jie

On Mon, May 11, 2015 at 1:29 PM, Ian Downes idow...@twitter.com.invalid
wrote:

 
  TLDR: We want to use a custom network isolator, but there is no way to
  enable the 'network' namespace from within an isolator module.
 
 
  We are working on creating a custom network isolator as a Mesos module.
  However, the way Mesos Slave is setup, there is no way to enable
 'network'
  namespace for the executor without enabling the 'port-mapping' isolator.
  This is due to the fact that the LinuxLauncher looks at the '--isolation'
  flag to figure out the list of namespaces to be enabled. The same problem
  would exist if one were to write a custom pid or filesystem isolation
  module.
 

 Curious, are these going to be open source and added to the codebase or
 will they be proprietary modules? What specifically is lacking in the
 existing network and pid isolators? Could we extend those?

 So, there are a couple of question:
 
  1. With the current Mesos source code, is there a way to specify the
  'network/port_mapping' isolator in a way that it doesn't do the actual
 work
  of mapping the ports (e.g., without specifying any port-mapping specific
  flags)? If this works, we can just specify this isolator on the slave
  command line and it would force the LinuxLauncher to create a new network
  namespace.


 No, as written they're coupled.

 2. Is it reasonable to have a separate mechanism to specify what namespaces
  should be created/enabled for an executor if we don't want to use the
  in-built isolators such as pid and port-mapping?


 Yes. The simplest (cleanest?) way that I see would be to refactor the
 launcher to take the desired flags when executing the executor, i.e.,
 (Linux)Launcher::fork() takes the namespace flags. The launcher would be
 directed which namespaces to create by the caller, not inferring them
 itself from any flags: the MesosContainerizer in turn would determine this
 based on the isolators it was using for the container (querying them). This
 also facilitates the MesosContainerizer having different isolators, and
 thus namespaces, for different containers.

 WRT (2), one potential mechanism is to introduce a new flag, '--namespace'.
  The downside of creating such a low-level flag is that it provides little
  to no value to the end users. The end users shouldn't be concerned about
  which namespaces to enable and so on


 That seems unduly onerous to the user and almost as rigid.


  Another alternative is to create a decorator hook for the LinuxLauncher,
  which can force the LinuxLauncher to enable certain namespaces without
  having to look at the '--isolation' flag. The downside here is that the
  decorator will be literally setting up a few bits and nothing more.
 

 I don't think there's a need for a decorator hook, just refactoring to pass
 in through fork() is sufficient?

 Are there any other alternatives for a better and cleaner design (both long
  term and short term)?
 

 Happy to chat further about this.

 ian

Re: Suggestion: Mesos 0.22.1 point release

[Jie Yu]

 Now that MESOS-2601 has landed, shall we include it in 0.22.1(-rc5) too?


+1

On Fri, Apr 24, 2015 at 2:34 PM, Adam Bordelon a...@mesosphere.io wrote:

 Added MESOS-2643 to the cherry-pick spreadsheet
 https://docs.google.com/a/mesosphere.io/spreadsheets/d/1OzAWNjAL4zKtI-jOJqaQUcDNlnrNik2Dd7dHhwFLKcI/edit#gid=0
 .

 Now that MESOS-2601 has landed, shall we include it in 0.22.1(-rc5) too?

 On Wed, Apr 22, 2015 at 2:58 PM, Benjamin Mahler 
 bmah...@twitter.com.invalid wrote:

 Linked it with the release ticket as a blocker.

 The fix is committed.

 On Wed, Apr 22, 2015 at 2:53 PM, Benjamin Mahler bmah...@twitter.com
 wrote:

  One regression in 0.22.x we missed:
  https://issues.apache.org/jira/browse/MESOS-2643
 
  Here, the python bindings are not backwards compatible in that they
  disable implicit acknowledgements by default. The fix is trivial, and I
  have a review linked below. Can we get this in 0.22.1?
 
  https://reviews.apache.org/r/33452/
 
  On Tue, Apr 14, 2015 at 11:26 PM, Timothy Chen tnac...@gmail.com
 wrote:
 
  I also think we should push that fix for 0.23.0, it will take time to
  review and merge.
 
  Tim
 
  On Tue, Apr 14, 2015 at 10:17 PM, Benjamin Hindman
  b...@eecs.berkeley.edu wrote:
   Yes, fixing it in 0.23.0 SGTM.
  
   On Tue, Apr 14, 2015 at 10:02 PM, Jie Yu yujie@gmail.com
 wrote:
  
   I am just asking if you guys want to fix that for 0.22.1 or not. It
  sounds
   to me a non trivial fix. Given the bug is there for quite a while,
  maybe we
   can fix it in 0.23.0?
  
   - Jie
  
   On Tue, Apr 14, 2015 at 9:55 PM, Benjamin Hindman 
  b...@eecs.berkeley.edu
   wrote:
  
We are going to include MESOS-2614 (it's a really trivial fix).
   
Jie, where did you get MESOS-2601 from? That's definitely not in
 the
spreadsheet.
   
On Tue, Apr 14, 2015 at 7:40 PM, Jie Yu yujie@gmail.com
 wrote:
   
 Also, this one:
 https://issues.apache.org/jira/browse/MESOS-2601

 This sounds like a non trivial fix.

 - Jie

 On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com
 wrote:

   Per Nik's comment here:
 
  Based on input from Vinod and Adam; I will reduce the scope on
  the
point
   release to focus on MESOS-1795 and MESOS-2583.
   I will move the other tickets back to 0.23.0 if you don't
 have
  any
   objections - let me know if you have any tickets which were
regressions
  in
   0.22.0.
 
 
  I expected there to be fewer tickets in the spreadsheet, are
 the
   extra
  tickets (e.g.
 https://issues.apache.org/jira/browse/MESOS-2614)
   going
to
  be
  included after all?
 
  On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere 
 jo...@mesosphere.io
  
  wrote:
 
   I think the plan is to cut a new RC by sometime tomorrow.
 The
 spreadsheet
   is up-to-date, just need to cherry-pick and modify the
  change-log.
  
   Joris
  
   On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com
   wrote:
  
Hey Nik, any progress on this? Is the spreadsheet
 up-to-date?
   
On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon 
   a...@mesosphere.io
   wrote:
   
 Hi Adam,

 Yes, once we have finalized the scope of the point
 release,
Niklas
  will
 send out an announcement of Mesos 0.22.1-rc1 (release
   candidate)
  which
   we
 would love you to test any way you can. The email will
  contain
instructions
 for building the release candidate and voting in the
  thread.
   See
 the
   vote
 thread from 0.22.0-rc4 (became final):

   http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html

 The current thread is to collect suggestions for bug
 fixes
  to
 include
   in
 this point release.

 Cheers,
 -Adam-

 On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla 
 a...@avil.la
wrote:

  On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen 
  nik...@mesosphere.io
   
  wrote:
 
   Based on input from Vinod and Adam; I will reduce
 the
  scope
on
  the
 point
   release to focus on MESOS-1795 and MESOS-2583.
  
 
  Can I help test these in any way?
 
  --
  /adam
 

   
  
 

   
  
 
 
 

Re: Suggestion: Mesos 0.22.1 point release

[Jie Yu]

Tim's patch cause a few compiler warnings. I committed a fix (just added to
the spreadsheet).

On Fri, Apr 24, 2015 at 2:35 PM, Jie Yu j...@twitter.com wrote:

 Now that MESOS-2601 has landed, shall we include it in 0.22.1(-rc5) too?


 +1

 On Fri, Apr 24, 2015 at 2:34 PM, Adam Bordelon a...@mesosphere.io wrote:

 Added MESOS-2643 to the cherry-pick spreadsheet
 https://docs.google.com/a/mesosphere.io/spreadsheets/d/1OzAWNjAL4zKtI-jOJqaQUcDNlnrNik2Dd7dHhwFLKcI/edit#gid=0
 .

 Now that MESOS-2601 has landed, shall we include it in 0.22.1(-rc5) too?

 On Wed, Apr 22, 2015 at 2:58 PM, Benjamin Mahler 
 bmah...@twitter.com.invalid wrote:

 Linked it with the release ticket as a blocker.

 The fix is committed.

 On Wed, Apr 22, 2015 at 2:53 PM, Benjamin Mahler bmah...@twitter.com
 wrote:

  One regression in 0.22.x we missed:
  https://issues.apache.org/jira/browse/MESOS-2643
 
  Here, the python bindings are not backwards compatible in that they
  disable implicit acknowledgements by default. The fix is trivial, and I
  have a review linked below. Can we get this in 0.22.1?
 
  https://reviews.apache.org/r/33452/
 
  On Tue, Apr 14, 2015 at 11:26 PM, Timothy Chen tnac...@gmail.com
 wrote:
 
  I also think we should push that fix for 0.23.0, it will take time to
  review and merge.
 
  Tim
 
  On Tue, Apr 14, 2015 at 10:17 PM, Benjamin Hindman
  b...@eecs.berkeley.edu wrote:
   Yes, fixing it in 0.23.0 SGTM.
  
   On Tue, Apr 14, 2015 at 10:02 PM, Jie Yu yujie@gmail.com
 wrote:
  
   I am just asking if you guys want to fix that for 0.22.1 or not. It
  sounds
   to me a non trivial fix. Given the bug is there for quite a while,
  maybe we
   can fix it in 0.23.0?
  
   - Jie
  
   On Tue, Apr 14, 2015 at 9:55 PM, Benjamin Hindman 
  b...@eecs.berkeley.edu
   wrote:
  
We are going to include MESOS-2614 (it's a really trivial fix).
   
Jie, where did you get MESOS-2601 from? That's definitely not in
 the
spreadsheet.
   
On Tue, Apr 14, 2015 at 7:40 PM, Jie Yu yujie@gmail.com
 wrote:
   
 Also, this one:
 https://issues.apache.org/jira/browse/MESOS-2601

 This sounds like a non trivial fix.

 - Jie

 On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com
 wrote:

   Per Nik's comment here:
 
  Based on input from Vinod and Adam; I will reduce the scope
 on
  the
point
   release to focus on MESOS-1795 and MESOS-2583.
   I will move the other tickets back to 0.23.0 if you don't
 have
  any
   objections - let me know if you have any tickets which were
regressions
  in
   0.22.0.
 
 
  I expected there to be fewer tickets in the spreadsheet, are
 the
   extra
  tickets (e.g.
 https://issues.apache.org/jira/browse/MESOS-2614)
   going
to
  be
  included after all?
 
  On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere 
 jo...@mesosphere.io
  
  wrote:
 
   I think the plan is to cut a new RC by sometime tomorrow.
 The
 spreadsheet
   is up-to-date, just need to cherry-pick and modify the
  change-log.
  
   Joris
  
   On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com
   wrote:
  
Hey Nik, any progress on this? Is the spreadsheet
 up-to-date?
   
On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon 
   a...@mesosphere.io
   wrote:
   
 Hi Adam,

 Yes, once we have finalized the scope of the point
 release,
Niklas
  will
 send out an announcement of Mesos 0.22.1-rc1 (release
   candidate)
  which
   we
 would love you to test any way you can. The email will
  contain
instructions
 for building the release candidate and voting in the
  thread.
   See
 the
   vote
 thread from 0.22.0-rc4 (became final):

   http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html

 The current thread is to collect suggestions for bug
 fixes
  to
 include
   in
 this point release.

 Cheers,
 -Adam-

 On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla 
 a...@avil.la
wrote:

  On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen 
  nik...@mesosphere.io
   
  wrote:
 
   Based on input from Vinod and Adam; I will reduce
 the
  scope
on
  the
 point
   release to focus on MESOS-1795 and MESOS-2583.
  
 
  Can I help test these in any way?
 
  --
  /adam
 

   
  
 

   
  
 
 
 

Review Request 33413: Changed the isolator recover interface to take a set of orphan containers detected by the launcher.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33413/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2367
https://issues.apache.org/jira/browse/MESOS-2367


Repository: mesos


Description
---

Changed the isolator recover interface to take a set of orphan containers 
detected by the launcher.

The idea is to let each isolator only cleanup unknown orphans during 
recovery. The cleanup of known orphans are controlled by the containerizer. 
This patch passes the known orphans to each isolator. The actual cleanup logics 
will be in the later patches.


Diffs
-

  include/mesos/slave/isolator.hpp 7cbce426cbf80eedb0114ee2ae375ba758de 
  src/slave/containerizer/isolator.cpp a6ad1d565348062c80db11b3b27b1c7a0119e319 
  src/slave/containerizer/isolators/cgroups/cpushare.hpp 
f72ebb1d52ecd8ab4853f13f386b688db1eece4f 
  src/slave/containerizer/isolators/cgroups/cpushare.cpp 
41b2597098a81baffae19fa91d6c9a86cf60d429 
  src/slave/containerizer/isolators/cgroups/mem.hpp 
d510bc0f88863fe54d1c892282a41b709098fb11 
  src/slave/containerizer/isolators/cgroups/mem.cpp 
a7a83ef9ad4726aa139a92fc7f5917ed687d33f5 
  src/slave/containerizer/isolators/cgroups/perf_event.hpp 
9f35ed0ee2c2d749a329f5cb537c3257a94e5676 
  src/slave/containerizer/isolators/cgroups/perf_event.cpp 
4dfccc51035b234c31a9f73ca67b3bf0fd28441b 
  src/slave/containerizer/isolators/filesystem/shared.hpp 
764a45caf3805b3c2f51c167813e8351530dd183 
  src/slave/containerizer/isolators/filesystem/shared.cpp 
d5abea2a7948b0d62ab5f3720066d513ee7d9564 
  src/slave/containerizer/isolators/namespaces/pid.hpp 
6a7be802039f29d852edb0463a0748fd7cf71c4c 
  src/slave/containerizer/isolators/namespaces/pid.cpp 
eb35ae6e34fa46dd38c9a96e69d38a229b3678d3 
  src/slave/containerizer/isolators/network/port_mapping.hpp 
466cd82e69665af217d61392b739b9bba16e1e13 
  src/slave/containerizer/isolators/network/port_mapping.cpp 
ccdc44f465f204f674b859c429ba1a6ada51cd88 
  src/slave/containerizer/isolators/posix.hpp 
fc31cece3996a723aefeec14c4d2c9cea2db5016 
  src/slave/containerizer/isolators/posix/disk.hpp 
0ccb1738f6501dfa8c285da4fad0d1c9afbf272d 
  src/slave/containerizer/isolators/posix/disk.cpp 
d2ea3b149fbe997a81e7989dfc0f96d817f2ae8d 
  src/slave/containerizer/mesos/containerizer.hpp 
ae61a0fcd19f2ba808624312401f020121baf5d4 
  src/slave/containerizer/mesos/containerizer.cpp 
e4136095fca55637864f495098189ab3ad8d8fe7 
  src/tests/isolator.hpp 93537cb7f82ff0e44e0b53b3453fdd4879493435 

Diff: https://reviews.apache.org/r/33413/diff/


Testing
---

make check


Thanks,

Jie Yu

Review Request 33412: Made the launcher recover interface to return a set of orphan containers.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33412/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2367
https://issues.apache.org/jira/browse/MESOS-2367


Repository: mesos


Description
---

Made the launcher recover interface to return a set of orphan containers.

The idea is to report orphan containers to the containerizer so that the 
containerizer can initiate the destroy of the orphan containers asynchronously 
without blocking (or failing) the recovery.

In this patch, the launcher always returns an empty set of orphan containers.


Diffs
-

  src/slave/containerizer/launcher.hpp 95a7f764e819503eb94cc8bf09eeead29247a544 
  src/slave/containerizer/launcher.cpp eb798fadfb9b50e08ffaeae1da56129a1745fbab 
  src/slave/containerizer/linux_launcher.hpp 
60082c7eb8b77330911ac4fa38cc9ba795fc4051 
  src/slave/containerizer/linux_launcher.cpp 
b176ac126657ed8291dd817ceb61c04a68ff1d42 
  src/tests/launcher.hpp 81ae95c91b5baf11bac3da0c9317981242accd37 

Diff: https://reviews.apache.org/r/33412/diff/


Testing
---

make check


Thanks,

Jie Yu

Review Request 33414: Made MesosContainerizer not fail on recovery if the destroy of orphan containers fails.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33414/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2367
https://issues.apache.org/jira/browse/MESOS-2367


Repository: mesos


Description
---

Made MesosContainerizer not fail on recovery if the destroy of orphan 
containers fails.


Diffs
-

  src/slave/containerizer/mesos/containerizer.hpp 
ae61a0fcd19f2ba808624312401f020121baf5d4 
  src/slave/containerizer/mesos/containerizer.cpp 
e4136095fca55637864f495098189ab3ad8d8fe7 

Diff: https://reviews.apache.org/r/33414/diff/


Testing
---

make check


Thanks,

Jie Yu

Review Request 33415: Changed launchers and isolators to adapt to the new orphan cleanup semantics.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33415/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2367
https://issues.apache.org/jira/browse/MESOS-2367


Repository: mesos


Description
---

Changed launchers and isolators to adapt to the new orphan cleanup semantics.

See my description in https://reviews.apache.org/r/33413/.


Diffs
-

  src/slave/containerizer/isolators/cgroups/cpushare.cpp 
41b2597098a81baffae19fa91d6c9a86cf60d429 
  src/slave/containerizer/isolators/cgroups/mem.cpp 
a7a83ef9ad4726aa139a92fc7f5917ed687d33f5 
  src/slave/containerizer/isolators/cgroups/perf_event.cpp 
4dfccc51035b234c31a9f73ca67b3bf0fd28441b 
  src/slave/containerizer/isolators/namespaces/pid.cpp 
eb35ae6e34fa46dd38c9a96e69d38a229b3678d3 
  src/slave/containerizer/isolators/network/port_mapping.cpp 
ccdc44f465f204f674b859c429ba1a6ada51cd88 
  src/slave/containerizer/linux_launcher.hpp 
60082c7eb8b77330911ac4fa38cc9ba795fc4051 
  src/slave/containerizer/linux_launcher.cpp 
b176ac126657ed8291dd817ceb61c04a68ff1d42 
  src/slave/containerizer/mesos/containerizer.hpp 
ae61a0fcd19f2ba808624312401f020121baf5d4 
  src/tests/port_mapping_tests.cpp 36219e737c75a5942dfc206c10997d5bcaf619fe 

Diff: https://reviews.apache.org/r/33415/diff/


Testing
---

sudo make check

The new code is exercised by the exiting test: 
PortMappingMesosTest.ROOT_CleanUpOrphanTest


Thanks,

Jie Yu

Re: Review Request 33249: Send statusUpdate to scheduler on containerizer launch failure

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33249/#review81090
---



src/slave/slave.cpp
https://reviews.apache.org/r/33249/#comment131331

Instead of doing that in your way, can we just try to make sure 
`containerizer-wait` here will return a failure (or a Termination with some 
reason) when `containerizer-launch` fails. In that way, the 
`executorTerminated` will properly send status updates to the slave 
(TASK_LOST/TASK_FAILED).

Or am I missing something?


- Jie Yu


On April 21, 2015, 5:14 p.m., Jay Buffington wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33249/
 ---
 
 (Updated April 21, 2015, 5:14 p.m.)
 
 
 Review request for mesos, Ben Mahler, Timothy Chen, and Vinod Kone.
 
 
 Bugs: MESOS-2020
 https://issues.apache.org/jira/browse/MESOS-2020
 
 
 Repository: mesos
 
 
 Description
 ---
 
 When mesos is unable to launch the containerizer the scheduler should
 get a TASK_FAILED with a status message that includes the error the
 containerizer encounted when trying to launch.
 
 Introduces a new TaskStatus: REASON_CONTAINERIZER_LAUNCH_FAILED
 
 Fixes MESOS-2020
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
   src/slave/slave.cpp 8ec80ed26f338690e0a1e712065750ab77a724cd 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33249/diff/
 
 
 Testing
 ---
 
 I added test case to slave_test.cpp.  I also tried this with Aurora, supplied 
 a bogus docker image url and saw the docker pull failure stderr message in 
 Aurora's web UI.
 
 
 Thanks,
 
 Jay Buffington
 

Re: Review Request 33249: Send statusUpdate to scheduler on containerizer launch failure

[Jie Yu]

 On April 21, 2015, 11:25 p.m., Jie Yu wrote:
  src/slave/slave.cpp, lines 3065-3078
  https://reviews.apache.org/r/33249/diff/3/?file=938221#file938221line3065
 
  Instead of doing that in your way, can we just try to make sure 
  `containerizer-wait` here will return a failure (or a Termination with 
  some reason) when `containerizer-launch` fails. In that way, the 
  `executorTerminated` will properly send status updates to the slave 
  (TASK_LOST/TASK_FAILED).
  
  Or am I missing something?
 
 Jie Yu wrote:
 OK, I think I got confused by the ticket. There are actually two problems 
 here. The problem I am refering to is the fact that we don't send status 
 update to the scheduler if containerizer launch fails until executor 
 reregistration timeout happens. Since for docker containerizer, someone might 
 use a very large timeout value, ideally, the slave should send a status 
 update to the scheduler right after containerizer launch fails.
 
 After chat with Jay, the problem you guys are refering to is the fact 
 that the scheduler cannot disinguish between the case where the task has 
 failed vs. the case where the configuration of a task is not correct, because 
 in both cases, the scheduler will receive a TASK_FAILED/TASK_LOST.

To address the first problem, I think the simplest way is to add a 
containerizer-destroy(..) in executorLaunched when containerizer-launch 
fails. In that way, it's going to trigger containerizer-wait and thus send 
status update to the scheduler.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33249/#review81090
---


On April 21, 2015, 5:14 p.m., Jay Buffington wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33249/
 ---
 
 (Updated April 21, 2015, 5:14 p.m.)
 
 
 Review request for mesos, Ben Mahler, Timothy Chen, and Vinod Kone.
 
 
 Bugs: MESOS-2020
 https://issues.apache.org/jira/browse/MESOS-2020
 
 
 Repository: mesos
 
 
 Description
 ---
 
 When mesos is unable to launch the containerizer the scheduler should
 get a TASK_FAILED with a status message that includes the error the
 containerizer encounted when trying to launch.
 
 Introduces a new TaskStatus: REASON_CONTAINERIZER_LAUNCH_FAILED
 
 Fixes MESOS-2020
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
   src/slave/slave.cpp 8ec80ed26f338690e0a1e712065750ab77a724cd 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33249/diff/
 
 
 Testing
 ---
 
 I added test case to slave_test.cpp.  I also tried this with Aurora, supplied 
 a bogus docker image url and saw the docker pull failure stderr message in 
 Aurora's web UI.
 
 
 Thanks,
 
 Jay Buffington
 

Re: Review Request 33249: Send statusUpdate to scheduler on containerizer launch failure

[Jie Yu]

 On April 21, 2015, 11:25 p.m., Jie Yu wrote:
  src/slave/slave.cpp, lines 3065-3078
  https://reviews.apache.org/r/33249/diff/3/?file=938221#file938221line3065
 
  Instead of doing that in your way, can we just try to make sure 
  `containerizer-wait` here will return a failure (or a Termination with 
  some reason) when `containerizer-launch` fails. In that way, the 
  `executorTerminated` will properly send status updates to the slave 
  (TASK_LOST/TASK_FAILED).
  
  Or am I missing something?

OK, I think I got confused by the ticket. There are actually two problems here. 
The problem I am refering to is the fact that we don't send status update to 
the scheduler if containerizer launch fails until executor reregistration 
timeout happens. Since for docker containerizer, someone might use a very large 
timeout value, ideally, the slave should send a status update to the scheduler 
right after containerizer launch fails.

After chat with Jay, the problem you guys are refering to is the fact that the 
scheduler cannot disinguish between the case where the task has failed vs. the 
case where the configuration of a task is not correct, because in both cases, 
the scheduler will receive a TASK_FAILED/TASK_LOST.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33249/#review81090
---


On April 21, 2015, 5:14 p.m., Jay Buffington wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33249/
 ---
 
 (Updated April 21, 2015, 5:14 p.m.)
 
 
 Review request for mesos, Ben Mahler, Timothy Chen, and Vinod Kone.
 
 
 Bugs: MESOS-2020
 https://issues.apache.org/jira/browse/MESOS-2020
 
 
 Repository: mesos
 
 
 Description
 ---
 
 When mesos is unable to launch the containerizer the scheduler should
 get a TASK_FAILED with a status message that includes the error the
 containerizer encounted when trying to launch.
 
 Introduces a new TaskStatus: REASON_CONTAINERIZER_LAUNCH_FAILED
 
 Fixes MESOS-2020
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
   src/slave/slave.cpp 8ec80ed26f338690e0a1e712065750ab77a724cd 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33249/diff/
 
 
 Testing
 ---
 
 I added test case to slave_test.cpp.  I also tried this with Aurora, supplied 
 a bogus docker image url and saw the docker pull failure stderr message in 
 Aurora's web UI.
 
 
 Thanks,
 
 Jay Buffington
 

Re: Review Request 33329: Removed unnecessary freeaddrinfo in getIP if getaddrinfo returns error.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33329/#review80751
---

Ship it!



3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
https://reviews.apache.org/r/33329/#comment130863

+1


- Jie Yu


On April 18, 2015, 12:35 a.m., Chi Zhang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33329/
 ---
 
 (Updated April 18, 2015, 12:35 a.m.)
 
 
 Review request for mesos, Ben Mahler, Evelina Dumitrescu, and Jie Yu.
 
 
 Bugs: mesos-2636
 https://issues.apache.org/jira/browse/mesos-2636
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Removed unnecessary freeaddrinfo in getIP if getaddrinfo returns error.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
 3622165af064a1f0a9d461af0e1d0d88a352d4a8 
 
 Diff: https://reviews.apache.org/r/33329/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Chi Zhang
 

Re: Review Request 33257: Fixed recover tasks only by the intiated containerizer.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33257/#review80756
---



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130874

Maybe add a TODO here as well to remove this in 0.24?



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130879

maybe s/existing/known/?



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130875

Maybe use LOG(INFO) here because this is quite useful for debugging?



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130876

Ditto on LOG(INFO)



src/slave/containerizer/mesos/containerizer.cpp
https://reviews.apache.org/r/33257/#comment130883

Please add a NOTE about the fact that MesosContainerizer will try to 
recover docker command line executors created by slaves pre 0.23.0. What'll 
happen if that's the case?



src/slave/containerizer/mesos/containerizer.cpp
https://reviews.apache.org/r/33257/#comment130880

Ditto on LOG(INFO).



src/slave/slave.cpp
https://reviews.apache.org/r/33257/#comment130870

Any reason just copying the containerType, not the entire containerInfo? 
Will we need more than just the container type to be checkpointed in the future?

I am trying to understand your rationale. To me, it's more understandable 
to copy the entire containerInfo.



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130892

s/execId/executorId/

```
ExecutorID executorId;
executorId.set_value(UUID::random().toString());

ContainerID containerId;
containerId.set_value(UUID::random().toString());
```



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130893

s/exec/executor/



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130895

Do you need to set the frameworkId?



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130897

Ditto on naming. s/exec/executor/



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130898

Set the frameworkId?


- Jie Yu


On April 17, 2015, 7:07 p.m., Timothy Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33257/
 ---
 
 (Updated April 17, 2015, 7:07 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Ian Downes, Jie 
 Yu, and Till Toenshoff.
 
 
 Bugs: MESOS-2601
 https://issues.apache.org/jira/browse/MESOS-2601
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed recover tasks only by the intiated containerizer.
 Currently both mesos and docker containerizer recovers tasks that wasn't 
 started by themselves.
 The proposed fix is to record the intended containerizer in the checkpointed 
 executorInfo, and reuse that information on recover to know if the 
 containerizer should recover or not. We are free to modify the executorInfo 
 since it's not being used to relaunch any task.
 The external containerizer doesn't need to change since it is only recovering 
 containers that are returned by the containers script.
 
 
 Diffs
 -
 
   src/slave/containerizer/docker.hpp 6893684e6d199a5d69fc8bba8e60c4acaae9c3c9 
   src/slave/containerizer/docker.cpp f9fb07806e3b7d7d2afc1be3b8756eac23b32dcd 
   src/slave/containerizer/mesos/containerizer.cpp 
 e4136095fca55637864f495098189ab3ad8d8fe7 
   src/slave/slave.cpp a0595f93ce4720f5b9926326d01210460ccb0667 
   src/tests/containerizer_tests.cpp 5991aa628083dac7c5e8bf7ba297f4f9edeec05f 
   src/tests/docker_containerizer_tests.cpp 
 c772d4c836de18b0e87636cb42200356d24ec73d 
 
 Diff: https://reviews.apache.org/r/33257/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Timothy Chen
 

Re: Build failed in Jenkins: Mesos » clang,docker||Hadoop,ubuntu:14.10 #154

[Jie Yu]

double free @@

On Fri, Apr 17, 2015 at 3:56 PM, Benjamin Mahler bmah...@twitter.com
wrote:

 +jie

 Can you take a look?

 On Fri, Apr 17, 2015 at 3:51 PM, Apache Jenkins Server 
 jenk...@builds.apache.org wrote:

 See 
 https://builds.apache.org/job/Mesos/COMPILER=clang,LABEL=docker%7C%7CHadoop,OS=ubuntu%3A14.10/154/changes
 

 Changes:

 [vinodkone] Disable dmesg logging in jenkins build script.

 --
 [...truncated 87950 lines...]
 I0417 22:51:27.246206 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.247341 23015 leveldb.cpp:306] Persisting metadata (8
 bytes) to leveldb took 770526ns
 I0417 22:51:27.247375 23015 replica.cpp:323] Persisted replica status to
 VOTING
 I0417 22:51:27.250511 22989 leveldb.cpp:176] Opened db in 2.611364ms
 I0417 22:51:27.253052 22989 leveldb.cpp:183] Compacted db in 2.519284ms
 I0417 22:51:27.253111 22989 leveldb.cpp:198] Created db iterator in
 30734ns
 I0417 22:51:27.253150 22989 leveldb.cpp:204] Seeked to beginning of db in
 28742ns
 I0417 22:51:27.253188 22989 leveldb.cpp:273] Iterated through 1 keys in
 the db in 32144ns
 I0417 22:51:27.253221 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.256274 22989 leveldb.cpp:176] Opened db in 2.91878ms
 I0417 22:51:27.259227 22989 leveldb.cpp:183] Compacted db in 2.932472ms
 I0417 22:51:27.259287 22989 leveldb.cpp:198] Created db iterator in
 30732ns
 I0417 22:51:27.259326 22989 leveldb.cpp:204] Seeked to beginning of db in
 26962ns
 I0417 22:51:27.259363 22989 leveldb.cpp:273] Iterated through 1 keys in
 the db in 31402ns
 I0417 22:51:27.259395 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.259820 23020 recover.cpp:449] Starting replica recovery
 I0417 22:51:27.260025 23020 recover.cpp:475] Replica is in VOTING status
 I0417 22:51:27.260146 23020 recover.cpp:464] Recover process terminated
 I0417 22:51:27.263207 23021 registrar.cpp:313] Recovering registrar
 [   OK ] Strict/RegistrarTest.fetchTimeout/0 (51 ms)
 [ RUN  ] Strict/RegistrarTest.fetchTimeout/1
 Using temporary directory
 '/tmp/Strict_RegistrarTest_fetchTimeout_1_pKSVOO'
 I0417 22:51:27.291038 22989 leveldb.cpp:176] Opened db in 3.175751ms
 I0417 22:51:27.292300 22989 leveldb.cpp:183] Compacted db in 1.24202ms
 I0417 22:51:27.292358 22989 leveldb.cpp:198] Created db iterator in
 24829ns
 I0417 22:51:27.292377 22989 leveldb.cpp:204] Seeked to beginning of db in
 7902ns
 I0417 22:51:27.292388 22989 leveldb.cpp:273] Iterated through 0 keys in
 the db in 6253ns
 I0417 22:51:27.292415 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.293623 23011 leveldb.cpp:306] Persisting metadata (8
 bytes) to leveldb took 713330ns
 I0417 22:51:27.293654 23011 replica.cpp:323] Persisted replica status to
 VOTING
 I0417 22:51:27.297266 22989 leveldb.cpp:176] Opened db in 3.074596ms
 I0417 22:51:27.298435 22989 leveldb.cpp:183] Compacted db in 1.149528ms
 I0417 22:51:27.298511 22989 leveldb.cpp:198] Created db iterator in
 25044ns
 I0417 22:51:27.298534 22989 leveldb.cpp:204] Seeked to beginning of db in
 8292ns
 I0417 22:51:27.298545 22989 leveldb.cpp:273] Iterated through 0 keys in
 the db in 6043ns
 I0417 22:51:27.298573 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.299579 23019 leveldb.cpp:306] Persisting metadata (8
 bytes) to leveldb took 724303ns
 I0417 22:51:27.299609 23019 replica.cpp:323] Persisted replica status to
 VOTING
 I0417 22:51:27.303488 22989 leveldb.cpp:176] Opened db in 3.412592ms
 I0417 22:51:27.306718 22989 leveldb.cpp:183] Compacted db in 3.210262ms
 I0417 22:51:27.306776 22989 leveldb.cpp:198] Created db iterator in
 29649ns
 I0417 22:51:27.306813 22989 leveldb.cpp:204] Seeked to beginning of db in
 25497ns
 I0417 22:51:27.306859 22989 leveldb.cpp:273] Iterated through 1 keys in
 the db in 41214ns
 I0417 22:51:27.306910 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.310102 22989 leveldb.cpp:176] Opened db in 3.02626ms
 I0417 22:51:27.312993 22989 leveldb.cpp:183] Compacted db in 2.869062ms
 I0417 22:51:27.313052 22989 leveldb.cpp:198] Created db iterator in
 30682ns
 I0417 22:51:27.313091 22989 leveldb.cpp:204] Seeked to beginning of db in
 28522ns
 I0417 22:51:27.313128 22989 leveldb.cpp:273] Iterated through 1 keys in
 the db in 31376ns
 I0417 22:51:27.313161 22989 replica.cpp:744] Replica recovered with log
 positions 0 - 0 with 1 holes and 0 unlearned
 I0417 22:51:27.313639 23008 recover.cpp:449] Starting replica recovery
 I0417 22:51:27.314113 23015 recover.cpp:475] Replica is in VOTING status
 I0417 22:51:27.314254 23015 recover.cpp:464] Recover process terminated
 I0417 22:51:27.316705 23012 registrar.cpp:313] Recovering 

Re: Suggestion: Mesos 0.22.1 point release

[Jie Yu]

Also, this one:
https://issues.apache.org/jira/browse/MESOS-2601

This sounds like a non trivial fix.

- Jie

On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

  Per Nik's comment here:

 Based on input from Vinod and Adam; I will reduce the scope on the point
  release to focus on MESOS-1795 and MESOS-2583.
  I will move the other tickets back to 0.23.0 if you don't have any
  objections - let me know if you have any tickets which were regressions
 in
  0.22.0.


 I expected there to be fewer tickets in the spreadsheet, are the extra
 tickets (e.g. https://issues.apache.org/jira/browse/MESOS-2614) going to
 be
 included after all?

 On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere jo...@mesosphere.io
 
 wrote:

  I think the plan is to cut a new RC by sometime tomorrow. The spreadsheet
  is up-to-date, just need to cherry-pick and modify the change-log.
 
  Joris
 
  On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
   Hey Nik, any progress on this? Is the spreadsheet up-to-date?
  
   On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon a...@mesosphere.io
  wrote:
  
Hi Adam,
   
Yes, once we have finalized the scope of the point release, Niklas
 will
send out an announcement of Mesos 0.22.1-rc1 (release candidate)
 which
  we
would love you to test any way you can. The email will contain
   instructions
for building the release candidate and voting in the thread. See the
  vote
thread from 0.22.0-rc4 (became final):
http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html
   
The current thread is to collect suggestions for bug fixes to include
  in
this point release.
   
Cheers,
-Adam-
   
On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla a...@avil.la wrote:
   
 On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen 
 nik...@mesosphere.io
  
 wrote:

  Based on input from Vinod and Adam; I will reduce the scope on
 the
point
  release to focus on MESOS-1795 and MESOS-2583.
 

 Can I help test these in any way?

 --
 /adam

   
  
 

Re: Suggestion: Mesos 0.22.1 point release

[Jie Yu]

I am just asking if you guys want to fix that for 0.22.1 or not. It sounds
to me a non trivial fix. Given the bug is there for quite a while, maybe we
can fix it in 0.23.0?

- Jie

On Tue, Apr 14, 2015 at 9:55 PM, Benjamin Hindman b...@eecs.berkeley.edu
wrote:

 We are going to include MESOS-2614 (it's a really trivial fix).

 Jie, where did you get MESOS-2601 from? That's definitely not in the
 spreadsheet.

 On Tue, Apr 14, 2015 at 7:40 PM, Jie Yu yujie@gmail.com wrote:

  Also, this one:
  https://issues.apache.org/jira/browse/MESOS-2601
 
  This sounds like a non trivial fix.
 
  - Jie
 
  On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
Per Nik's comment here:
  
   Based on input from Vinod and Adam; I will reduce the scope on the
 point
release to focus on MESOS-1795 and MESOS-2583.
I will move the other tickets back to 0.23.0 if you don't have any
objections - let me know if you have any tickets which were
 regressions
   in
0.22.0.
  
  
   I expected there to be fewer tickets in the spreadsheet, are the extra
   tickets (e.g. https://issues.apache.org/jira/browse/MESOS-2614) going
 to
   be
   included after all?
  
   On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere 
  jo...@mesosphere.io
   
   wrote:
  
I think the plan is to cut a new RC by sometime tomorrow. The
  spreadsheet
is up-to-date, just need to cherry-pick and modify the change-log.
   
Joris
   
On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler 
benjamin.mah...@gmail.com
wrote:
   
 Hey Nik, any progress on this? Is the spreadsheet up-to-date?

 On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon a...@mesosphere.io
wrote:

  Hi Adam,
 
  Yes, once we have finalized the scope of the point release,
 Niklas
   will
  send out an announcement of Mesos 0.22.1-rc1 (release candidate)
   which
we
  would love you to test any way you can. The email will contain
 instructions
  for building the release candidate and voting in the thread. See
  the
vote
  thread from 0.22.0-rc4 (became final):
  http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html
 
  The current thread is to collect suggestions for bug fixes to
  include
in
  this point release.
 
  Cheers,
  -Adam-
 
  On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla a...@avil.la
 wrote:
 
   On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen 
   nik...@mesosphere.io

   wrote:
  
Based on input from Vinod and Adam; I will reduce the scope
 on
   the
  point
release to focus on MESOS-1795 and MESOS-2583.
   
  
   Can I help test these in any way?
  
   --
   /adam
  
 

   
  
 

Re: Review Request 32891: Support for entering and configuring a Linux chroot.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32891/#review79936
---

Ship it!


Could you add a TODO for adding a unit test for fs::enter? You probably can 
construct the new root by copying files from host file systems and do a clone 
using subprocess.


src/linux/fs.hpp
https://reviews.apache.org/r/32891/#comment129584

Do you want to expose these functions, or these are just helper functions 
used by fs::enter? Let's not expose these functions until we find a use case.



src/linux/fs.hpp
https://reviews.apache.org/r/32891/#comment129586

Can you add some comments (i.e., a short summary) about this interface?

More specifically, you should call out in the comments that this function 
should only be used with mount namespace.



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129589

One additional line above.



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129592

```
namespace internal {

struct Mount
{
  ...
};

struct Symlink
{
  ...
};

} // namespace internal {
```

Does the above work?



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129593

Put '{' to the next line.



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129614

Mind putting this function as well as createStandardDevices into internal 
namespace as they are not exposed.



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129629

One blank line above.



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129626

/tmp exists in the new root and is writable;...


- Jie Yu


On April 6, 2015, 6 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32891/
 ---
 
 (Updated April 6, 2015, 6 p.m.)
 
 
 Review request for mesos, Chi Zhang, Jay Buffington, Jie Yu, and James Peach.
 
 
 Bugs: MESOS-2350
 https://issues.apache.org/jira/browse/MESOS-2350
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Support for entering and configuring a Linux chroot.
 
 
 Diffs
 -
 
   src/linux/fs.hpp d7832a4b3761c48be6c1ccef58a30ee31c70dc1b 
   src/linux/fs.cpp 1c9cf3f2ffead37148e4f6a81cefdbb97f679b09 
 
 Diff: https://reviews.apache.org/r/32891/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ian Downes
 

Re: Review Request 32891: Support for entering and configuring a Linux chroot.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32891/#review79947
---



src/linux/fs.cpp
https://reviews.apache.org/r/32891/#comment129631

Copy comments from the other review, can you support `Optionstring 
options` for fs::mount as well?


- Jie Yu


On April 6, 2015, 6 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32891/
 ---
 
 (Updated April 6, 2015, 6 p.m.)
 
 
 Review request for mesos, Chi Zhang, Jay Buffington, Jie Yu, and James Peach.
 
 
 Bugs: MESOS-2350
 https://issues.apache.org/jira/browse/MESOS-2350
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Support for entering and configuring a Linux chroot.
 
 
 Diffs
 -
 
   src/linux/fs.hpp d7832a4b3761c48be6c1ccef58a30ee31c70dc1b 
   src/linux/fs.cpp 1c9cf3f2ffead37148e4f6a81cefdbb97f679b09 
 
 Diff: https://reviews.apache.org/r/32891/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ian Downes
 

Re: Review Request 31444: Support chrooting in MesosContainerizer launch helper.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31444/#review79948
---


Nice test!


src/linux/fs.cpp
https://reviews.apache.org/r/31444/#comment129633

s/typede/types/



src/linux/fs.cpp
https://reviews.apache.org/r/31444/#comment129634

Remember to move '{' to the next line.



src/linux/fs.cpp
https://reviews.apache.org/r/31444/#comment129635

Ditto.



src/slave/containerizer/mesos/launch.cpp
https://reviews.apache.org/r/31444/#comment129636

Why do you need this include? Seems that list is not used.



src/slave/containerizer/mesos/launch.cpp
https://reviews.apache.org/r/31444/#comment129637

Ditto.



src/slave/containerizer/mesos/launch.cpp
https://reviews.apache.org/r/31444/#comment129639

Could you change the flag help string for --directory stating that if 
--rootfs is used, the 'directory' should be relative to the new root?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129661

Maybe add a comment about this method? What does it do?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129642

```
if (os::system(...) != 0) {
  return ErrnoError(...);
}
```



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129643

Ditto. Also, do you also wanna copy /lib as well? Looking at my ubuntu 
trusty 64:

```
vagrant@vagrant-ubuntu-trusty-64:~$ uname -a
Linux vagrant-ubuntu-trusty-64 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 
03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant-ubuntu-trusty-64:~$ ls /
bin  boot  dev  etc  home  initrd.img  lib  lib64  lost+found  media  mnt  
opt  proc  root  run  sbin  srv  sys  tmp  usr  vagrant  var  vmlinuz  workspace
vagrant@vagrant-ubuntu-trusty-64:~$ ls /lib64
ld-linux-x86-64.so.2
vagrant@vagrant-ubuntu-trusty-64:~$ ldd /bin/sh
linux-vdso.so.1 =  (0x7fff23331000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c8e24)
/lib64/ld-linux-x86-64.so.2 (0x7f8c8e831000)
```



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129644

Why slave mount? Shouldn't this be a SHARED mount?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129651

Please refine the comments here;)



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129652

Why `// XXX` at the end of the line?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129658

Do you need stdin? Or you can just use PATH(/dev/null)?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129659

Any reason you want to do this?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129655

s/stack/Stack/



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129660

Do you still need this?



src/tests/launch_tests.cpp
https://reviews.apache.org/r/31444/#comment129657

Add one more blank line above.


- Jie Yu


On April 8, 2015, 3:24 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31444/
 ---
 
 (Updated April 8, 2015, 3:24 p.m.)
 
 
 Review request for mesos, Chi Zhang, Dominic Hamon, Jay Buffington, Jie Yu, 
 and James Peach.
 
 
 Bugs: MESOS-2350
 https://issues.apache.org/jira/browse/MESOS-2350
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Optionally take a path that the launch helper should chroot to before 
 exec'ing the executor. It is assumed that the work directory is mounted to 
 the appropriate location under the chroot. In particular, the path to the 
 executor must be relative to the chroot.
 
 Configuration that should be private to the chroot is done during the launch, 
 e.g. mounting proc and statically configuring basic devices. It is assumed 
 that other configuration, e.g., preparing the image, mounting in volumes or 
 persistent resources, is done by the caller.
 
 Mounts can be made to the chroot (e.g., updating the volumes or persistent 
 resources) and they will propagate in to the container but mounts made inside 
 the container will not propagate out to the host.
 
 It currently assumes that at least {{chroot}}/tmp is writeable and that mount 
 points {{chroot}}/{tmp,dev,proc,sys} exist in the chroot.
 
 This is specific to Linux.
 
 
 Diffs
 -
 
   src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
   src/linux/fs.cpp 1c9cf3f2ffead37148e4f6a81cefdbb97f679b09 
   src/slave/containerizer/mesos/launch.hpp 
 7c8b535746b5ce9add00afef86fdb6faefb5620e 
   src/slave/containerizer/mesos/launch.cpp 
 2f2d60e2011f60ec711d3b29fd2c157e30c83c34 
   src/tests

Re: Review Request 32978: Add os::stat::inode to stout.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32978/#review79961
---

Ship it!


Ship It!

- Jie Yu


On April 8, 2015, 3:24 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32978/
 ---
 
 (Updated April 8, 2015, 3:24 p.m.)
 
 
 Review request for mesos, Chi Zhang, Jie Yu, and Paul Brett.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Add os::stat::inode to stout.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/os/stat.hpp 
 af940a48b161c194f2efb529b3d589c543b12f61 
 
 Diff: https://reviews.apache.org/r/32978/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ian Downes
 

Re: Review Request 33040: Expose qdisc statistics from libnl

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33040/#review79742
---


Could you please create a diff with master branch please?

- Jie Yu


On April 10, 2015, 7:19 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33040/
 ---
 
 (Updated April 10, 2015, 7:19 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Expose qdisc statistics from libnl
 
 
 Diffs
 -
 
   configure.ac 868c0413a2e2307ae8ab2211f56874595759b139 
   src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
   src/linux/routing/queueing/fq_codel.hpp 
 4f67ab7d64afea96a07dfcf36769a9c667749a00 
   src/linux/routing/queueing/fq_codel.cpp 
 02ad8df7814c0e549a9ca9aef39777684e6abdcb 
   src/linux/routing/queueing/ingress.hpp 
 b323a7f6daed828327d6d9e9740df81582e0ba2b 
   src/linux/routing/queueing/ingress.cpp 
 47c73376097d70819defdee31a6d1e446df6b8ba 
   src/linux/routing/queueing/internal.hpp 
 7c6c4d3d960b9a4bf44dcf482212317522353d69 
   src/linux/routing/queueing/statistics.hpp PRE-CREATION 
   src/linux/routing/queueing/statistics.cpp PRE-CREATION 
   src/tests/routing_tests.cpp 7cc3b57a3b71544874557d2b1cf88a241b7062ba 
 
 Diff: https://reviews.apache.org/r/33040/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Re: Review Request 33040: Expose qdisc statistics from libnl

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33040/#review79743
---


Seems that it's still not rebased.

- Jie Yu


On April 10, 2015, 7:47 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33040/
 ---
 
 (Updated April 10, 2015, 7:47 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Expose qdisc statistics from libnl
 
 
 Diffs
 -
 
   configure.ac 868c0413a2e2307ae8ab2211f56874595759b139 
   src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
   src/linux/routing/queueing/fq_codel.hpp 
 4f67ab7d64afea96a07dfcf36769a9c667749a00 
   src/linux/routing/queueing/fq_codel.cpp 
 02ad8df7814c0e549a9ca9aef39777684e6abdcb 
   src/linux/routing/queueing/ingress.hpp 
 b323a7f6daed828327d6d9e9740df81582e0ba2b 
   src/linux/routing/queueing/ingress.cpp 
 47c73376097d70819defdee31a6d1e446df6b8ba 
   src/linux/routing/queueing/internal.hpp 
 7c6c4d3d960b9a4bf44dcf482212317522353d69 
   src/linux/routing/queueing/statistics.hpp PRE-CREATION 
   src/linux/routing/queueing/statistics.cpp PRE-CREATION 
   src/tests/routing_tests.cpp 7cc3b57a3b71544874557d2b1cf88a241b7062ba 
 
 Diff: https://reviews.apache.org/r/33040/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Re: Review Request 32984: Added an example framework for testing persistent volumes.

[Jie Yu]

 On April 10, 2015, 6:40 p.m., Vinod Kone wrote:
  LGTM. Are you planning to add similar ones for java and python, because 
  that's what framework writers would be most intersted in. A TODO for now is 
  fine. Alternatively, you can convert the current example frameworks (cpp, 
  java and python) to use persistent volumes instead of writing new ones.

Created
https://issues.apache.org/jira/browse/MESOS-2610


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32984/#review79727
---


On April 8, 2015, 7:08 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32984/
 ---
 
 (Updated April 8, 2015, 7:08 p.m.)
 
 
 Review request for mesos, Ben Mahler and Vinod Kone.
 
 
 Bugs: MESOS-2404
 https://issues.apache.org/jira/browse/MESOS-2404
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Added an example framework for testing persistent volumes.
 
 
 Diffs
 -
 
   src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
   src/examples/persistent_volume_framework.cpp PRE-CREATION 
   src/tests/examples_tests.cpp 5222b6d5e66736495b743367b5731bb9094410fd 
   src/tests/persistent_volume_framework_test.sh PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32984/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 33040: Expose qdisc statistics from libnl

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33040/#review79776
---



configure.ac
https://reviews.apache.org/r/33040/#comment129351

See my comments. You don't need that anymore.



src/linux/routing/queueing/internal.hpp
https://reviews.apache.org/r/33040/#comment129338

The build machine might have libnl3.2.26 while the production machine might 
not. So I would rather not use ifdef here.

Simply use the first version and get rid of any dependency to 
rtnl_tc_stat2str. Adding a TODO here is sufficient.

Also, this is header file, the compiler will create a copy of 'tcNames' in 
each cpp file that includes this header. Please avoid that. See my comments 
below.



src/linux/routing/queueing/internal.hpp
https://reviews.apache.org/r/33040/#comment129346

Please be consistent with the link::get above:

```
if (qdisc.isError()) {
  ...
} else if (qdisk.isNone()) {
  ...
}
```



src/linux/routing/queueing/internal.hpp
https://reviews.apache.org/r/33040/#comment129350

You probably want to create a hashmap:

```
// TODO(..): This is a workaround...
hashmapint, std::string names;
names[(int) RTNL_TC_PACKETS] = packets;
names[(int) RTNL_TC_BYTES] = bytes;
...
names[(int) RTNL_TC_OVERLIMITS] = overlimits;

hashmapstd::string, uint64_t results;
for(int i = 0; i  (int) RTNL_TC_STATS_MAX; i++) {
  results[names[i]] = rtnl_tc_get_stat(
  TC_CAST(qdisc.get().get(),
  (rtnl_tc_stat) i);
}

return results;
```


- Jie Yu


On April 10, 2015, 11:17 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33040/
 ---
 
 (Updated April 10, 2015, 11:17 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Expose qdisc statistics from libnl
 
 
 Diffs
 -
 
   configure.ac 868c041 
   src/linux/routing/queueing/fq_codel.hpp 4f67ab7 
   src/linux/routing/queueing/fq_codel.cpp 02ad8df 
   src/linux/routing/queueing/ingress.hpp b323a7f 
   src/linux/routing/queueing/ingress.cpp 47c7337 
   src/linux/routing/queueing/internal.hpp 7c6c4d3 
   src/tests/routing_tests.cpp 7cc3b57 
 
 Diff: https://reviews.apache.org/r/33040/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Review Request 32983: Fixed a bug regarding setting work_dir for a local cluster.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32983/
---

Review request for mesos, Ben Mahler and Vinod Kone.


Repository: mesos


Description
---

Fixed a bug regarding setting work_dir for a local cluster.


Diffs
-

  src/local/local.cpp 19083368212b24ce1afef3a5f91d48766d1cd55e 

Diff: https://reviews.apache.org/r/32983/diff/


Testing
---

make check


Thanks,

Jie Yu

Review Request 32984: Added an example framework for testing persistent volumes.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32984/
---

Review request for mesos, Ben Mahler and Vinod Kone.


Bugs: MESOS-2404
https://issues.apache.org/jira/browse/MESOS-2404


Repository: mesos


Description
---

Added an example framework for testing persistent volumes.


Diffs
-

  src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
  src/examples/persistent_volume_framework.cpp PRE-CREATION 
  src/tests/examples_tests.cpp 5222b6d5e66736495b743367b5731bb9094410fd 
  src/tests/persistent_volume_framework_test.sh PRE-CREATION 

Diff: https://reviews.apache.org/r/32984/diff/


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 32955: Simplified ROOT_CGROUPS_Listen test.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32955/#review79395
---

Ship it!


Great cleanup!


src/tests/cgroups_tests.cpp
https://reviews.apache.org/r/32955/#comment128705

Any reason you want to remove this?



src/tests/cgroups_tests.cpp
https://reviews.apache.org/r/32955/#comment128703

Use AWAIT_READY?


- Jie Yu


On April 8, 2015, 2:29 a.m., Chi Zhang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32955/
 ---
 
 (Updated April 8, 2015, 2:29 a.m.)
 
 
 Review request for mesos, Ian Downes and Jie Yu.
 
 
 Bugs: mesos-2573
 https://issues.apache.org/jira/browse/mesos-2573
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Simplified ROOT_CGROUPS_Listen test.
 
 
 Diffs
 -
 
   src/tests/cgroups_tests.cpp e18aed1feca182da89a117f81bed0897a00fb0ef 
 
 Diff: https://reviews.apache.org/r/32955/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Chi Zhang
 

Re: Review Request 32139: Add 'Resource::ReservationInfo' protobuf message.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32139/#review79404
---

Ship it!


Ship It!

- Jie Yu


On April 7, 2015, 9:52 p.m., Michael Park wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32139/
 ---
 
 (Updated April 7, 2015, 9:52 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
 
 
 Bugs: MESOS-2475
 https://issues.apache.org/jira/browse/MESOS-2475
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The beginning of `Resource::ReservationInfo`. This patch only introduces the 
 `principal` field.
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
 
 Diff: https://reviews.apache.org/r/32139/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Michael Park
 

Re: Review Request 32984: Added an example framework for testing persistent volumes.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32984/
---

(Updated April 8, 2015, 7:08 p.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


Changes
---

Changed the commands to better catch errors.


Bugs: MESOS-2404
https://issues.apache.org/jira/browse/MESOS-2404


Repository: mesos


Description
---

Added an example framework for testing persistent volumes.


Diffs (updated)
-

  src/Makefile.am 9c01f5d6c692f835100e7cade928748cc4763cc8 
  src/examples/persistent_volume_framework.cpp PRE-CREATION 
  src/tests/examples_tests.cpp 5222b6d5e66736495b743367b5731bb9094410fd 
  src/tests/persistent_volume_framework_test.sh PRE-CREATION 

Diff: https://reviews.apache.org/r/32984/diff/


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 32398: Persist the reservation state on the slave.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32398/#review79445
---

Ship it!


Nice tests!


src/common/resources.cpp
https://reviews.apache.org/r/32398/#comment128831

Since we already have `isReserved`. How about calling it 
`isDynamicallyReserved`?



src/common/resources_utils.cpp
https://reviews.apache.org/r/32398/#comment128838

So bad that we are effectively duplicating the logics in Resources::apply 
here. But I couldn't come up with a better way without introducing stripping.

Maybe add a command about what we are doing here. We are effectively 
infering offer operations from checkpointed resources and apply them to the 
totalResources.



src/tests/reservation_tests.cpp
https://reviews.apache.org/r/32398/#comment128840

I think for initialization list, I considently remove leading and tailing 
spaces around { and }:

```
{offer.id()},
{RESERVE(...), ..., UNRESERVE(..)}
```



src/tests/reservation_tests.cpp
https://reviews.apache.org/r/32398/#comment128841

Do you want to say something about persitent volumes in the comment?:)



src/tests/reservation_tests.cpp
https://reviews.apache.org/r/32398/#comment128842

compatible or not compatible?


- Jie Yu


On April 8, 2015, 6:38 p.m., Michael Park wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32398/
 ---
 
 (Updated April 8, 2015, 6:38 p.m.)
 
 
 Review request for mesos and Alexander Rukletsov.
 
 
 Bugs: MESOS-2491
 https://issues.apache.org/jira/browse/MESOS-2491
 
 
 Repository: mesos
 
 
 Description
 ---
 
 * Added `isDynamicReservation(resource)` which returns true if the resource 
 is either a dynamic role reservation or a framework reservation.
 * Added the `isDynamicReservation` condition onto `needCheckpointing`.
 * Updated the `applyCheckpointedResources` to consider dynamic reservations.
 * Added tests.
 
 
 Diffs
 -
 
   include/mesos/resources.hpp 56affd45e1e71e96ff5778b43271f81b9b9a9e4d 
   src/common/resources.cpp 2c99b6884d7296099e19e2e3182cbe11b5e1e059 
   src/common/resources_utils.cpp fe04d57227fa193d6d11d2f76529c46aea74c6a1 
   src/tests/reservation_tests.cpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32398/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Michael Park
 

Re: Review Request 32149: Enable 'Resources::apply' to handle reservation operations.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32149/#review79430
---



src/common/resources.cpp
https://reviews.apache.org/r/32149/#comment128786

Do you need to call validate(operation.reserve().resources()) first (like 
we did in CREATE/DESTROY)? Do you also want to check if each resource is 
dynamically reserved (i.e., has ReservationInfo, role != `*`)?


- Jie Yu


On April 7, 2015, 10:25 p.m., Michael Park wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32149/
 ---
 
 (Updated April 7, 2015, 10:25 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
 
 
 Bugs: MESOS-2477
 https://issues.apache.org/jira/browse/MESOS-2477
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   src/common/resources.cpp 2c99b6884d7296099e19e2e3182cbe11b5e1e059 
   src/tests/resources_tests.cpp 7e0ad98c3366f647f190363a0e6b576dbfc7d415 
 
 Diff: https://reviews.apache.org/r/32149/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Michael Park
 

Re: Review Request 32140: Enable 'Resources' to handle 'Resource::ReservationInfo'.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32140/#review79410
---



src/common/resources.cpp
https://reviews.apache.org/r/32140/#comment128732

I probably would split the logic like below so that it's more modular. 
Also, I think the current semantics for DiskInfo matching is a little weired 
(my fault) and I don't think we have a use case for now. So let's make it 
consistent with the ReservationInfo check (and remove the NOTE). You probably 
need to adjust some ResourcesTest.

```
if (left.name() != right.name() ||
left.type() != right.type() ||
left.role() != right.role()) {
  return false;
}

// Check if ReservationInfo matches.
if (left.has_reservation() != right.has_reservation()) {
  return false;
}

if (left.has_reservation()  left.reservation() != right.reservation())) {
  return false;
}

// Check if DiskInfo matches.
if (left.has_disk() != right.has_disk()) {
  return false;
}

if (left.has_disk()  left.disk() != right.disk()) {
  return false;
}
```



src/common/resources.cpp
https://reviews.apache.org/r/32140/#comment128738

Ditto on modularity.

```
if (left.name() != right.name() ||
left.type() != right.type() ||
left.role() != right.role()) {
  return false;
}

// Check ReservationInfo.
if (left.has_reservation() != right.has_reservation()) {
  return false;
}

if (left.has_reservation()  left.reservation() != right.reservation()) {
  return false;
}

// Check DiskInfo.
if (left.has_disk() != right.has_disk()) {
  return false;
}

if (left.has_disk()  left.disk() != right.disk()) {
  return false;
}

// TODO(jieyu): Even if two 
if (left.has_disk()  left.disk().has_persistence()) {
  return false;
}

return true;
```



src/common/resources.cpp
https://reviews.apache.org/r/32140/#comment128753

Ditto on modularity.

```
if (left.name() != right.name() ||
left.type() != right.type() ||
left.role() != right.role()) {
  return false;
}

// Check ReservationInfo.
if (left.has_reservation() != right.has_reservation()) {
  return false;
}

if (left.has_reservation()  left.reservation() != right.reservation()) {
  return false;
}

// Check DiskInfo.
if (left.has_disk() != right.has_disk()) {
  return false;
}

if (left.has_disk()  left.disk() != right.disk()) {
  return false;
}

if (left.has_disk()  left.disk().has_persistence()  left != right) {
  return false;
}

return true;
```



src/common/resources.cpp
https://reviews.apache.org/r/32140/#comment128760

The semantics of this function becomes a little weired now. For example, 
for a resource that has `role == *` and has reservation set, 
`isReserved(resource, *)` is going to return `true`? Given that 'resource' is 
invalid, we should return a `false` in that case?


- Jie Yu


On April 7, 2015, 9:56 p.m., Michael Park wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32140/
 ---
 
 (Updated April 7, 2015, 9:56 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
 
 
 Bugs: MESOS-2476
 https://issues.apache.org/jira/browse/MESOS-2476
 
 
 Repository: mesos
 
 
 Description
 ---
 
 `Resource::ReservationInfo` was introduced in 
 [r32139](https://reviews.apache.org/r/32139). We need to consider it in our 
 `Resources` class implementation.
 
 ### `Resources::flatten`
 
 `flatten` is used as the utility function to cross reservation boundaries 
 without affecting the given resources. Since the reservation is now specified 
 by the (`role`, `reservation`) pair, `flatten` needs to consider 
 `ReservationInfo` as well.
 
 ### `Resources::validate`
 
 If `role == *`, then `reservation` field must not be set.
 
 ### `Resources` comparators
 
 `operator==`, `addable` and `substractable` need to test for 
 `ReservationInfo` as well.
 
 
 Diffs
 -
 
   include/mesos/resources.hpp 56affd45e1e71e96ff5778b43271f81b9b9a9e4d 
   src/common/resources.cpp 2c99b6884d7296099e19e2e3182cbe11b5e1e059 
   src/tests/mesos.hpp 0e98572a62ae05437bd2bc800c370ad1a0c43751 
   src/tests/resources_tests.cpp 7e0ad98c3366f647f190363a0e6b576dbfc7d415 
 
 Diff: https://reviews.apache.org/r/32140/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Michael Park
 

Review Request 32820: Fixed the non-POD global variable in perf sampler.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32820/
---

Review request for mesos, Ben Mahler and Ian Downes.


Repository: mesos


Description
---

Fixed the non-POD global variable in perf sampler.


Diffs
-

  src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 

Diff: https://reviews.apache.org/r/32820/diff/


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 32805: Terminated the perf subprocess once the parent exits.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32805/
---

(Updated April 3, 2015, 5:11 p.m.)


Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Terminated the perf subprocess once the parent exits.

The idea is to have a nanny process which installs a SIGTERM handler which will 
kill the process group (of course, we need to put the nanny and perf process to 
the same process group). We set the death signal of the nanny process to be 
SIGTERM. In that way, when slave exits, the nanny process will receive a 
SIGTERM, which will then kill all processes in the process group.


Diffs
-

  src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 

Diff: https://reviews.apache.org/r/32805/diff/


Testing
---

sudo make check

I also manually verified it by terminating the slave while perf is in progress. 
The perf is killed immediately.


Thanks,

Jie Yu

Re: Review Request 32820: Fixed the non-POD global variable in perf sampler.

[Jie Yu]

 On April 3, 2015, 8:34 p.m., Ben Mahler wrote:
  src/linux/perf.cpp, lines 46-51
  https://reviews.apache.org/r/32820/diff/1/?file=914812#file914812line46
 
  char[]
  
  Also noticed many of our other constants are not static, we may want 
  to do a sweep?

Done. I'll do the sweep next week.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32820/#review78829
---


On April 3, 2015, 5:01 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32820/
 ---
 
 (Updated April 3, 2015, 5:01 p.m.)
 
 
 Review request for mesos, Ben Mahler and Ian Downes.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed the non-POD global variable in perf sampler.
 
 
 Diffs
 -
 
   src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 
 
 Diff: https://reviews.apache.org/r/32820/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32805: Terminated the perf subprocess once the parent exits.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32805/
---

(Updated April 3, 2015, 9:29 p.m.)


Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Changes
---

Review comments. Added more comments.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Terminated the perf subprocess once the parent exits.

The idea is to have a nanny process which installs a SIGTERM handler which will 
kill the process group (of course, we need to put the nanny and perf process to 
the same process group). We set the death signal of the nanny process to be 
SIGTERM. In that way, when slave exits, the nanny process will receive a 
SIGTERM, which will then kill all processes in the process group.


Diffs (updated)
-

  src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 

Diff: https://reviews.apache.org/r/32805/diff/


Testing
---

sudo make check

I also manually verified it by terminating the slave while perf is in progress. 
The perf is killed immediately.


Thanks,

Jie Yu

Re: Review Request 32805: Terminated the perf subprocess once the parent exits.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32805/
---

(Updated April 3, 2015, 9:29 p.m.)


Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Terminated the perf subprocess once the parent exits.

The idea is to have a nanny process which installs a SIGTERM handler which will 
kill the process group (of course, we need to put the nanny and perf process to 
the same process group). We set the death signal of the nanny process to be 
SIGTERM. In that way, when slave exits, the nanny process will receive a 
SIGTERM, which will then kill all processes in the process group.


Diffs
-

  src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 

Diff: https://reviews.apache.org/r/32805/diff/


Testing
---

sudo make check

I also manually verified it by terminating the slave while perf is in progress. 
The perf is killed immediately.


Thanks,

Jie Yu

Review Request 32833: Added os::signals::install to install signal handlers.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32833/
---

Review request for mesos and Vinod Kone.


Repository: mesos


Description
---

Added os::signals::install to install signal handlers.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/os/signals.hpp 
30232f50cc72a79acd21499fe7602c9bcd624ff6 

Diff: https://reviews.apache.org/r/32833/diff/


Testing
---

Tested in the later patch.


Thanks,

Jie Yu

Review Request 32805: Terminated the perf subprocess once the parent exits.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32805/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Terminated the perf subprocess once the parent exits.

The idea is to have a nanny process which installs a SIGTERM handler which will 
kill the process group (of course, we need to put the nanny and perf process to 
the same process group). We set the death signal of the nanny process to be 
SIGTERM. In that way, when slave exits, the nanny process will receive a 
SIGTERM, which will then kill all processes in the process group.


Diffs
-

  src/linux/perf.cpp cad6c80e2a9608ff02fc2b8976efba52713dd5a8 

Diff: https://reviews.apache.org/r/32805/diff/


Testing
---

sudo make check

I also manually verified it by terminating the slave while perf is in progress. 
The perf is killed immediately.


Thanks,

Jie Yu

Re: Review Request 32694: Set death signal for forked du processes for posix/disk isolator.

[Jie Yu]

 On April 2, 2015, 6:40 p.m., Ben Mahler wrote:
  src/slave/containerizer/isolators/posix/disk.cpp, lines 363-367
  https://reviews.apache.org/r/32694/diff/3/?file=912579#file912579line363
 
  I'm still not sure why this is best-effort, since we never expect this 
  to fail, can we just return its status code? It would be nice to find out 
  if this isn't working as expected.
  
  This is even more important for 'perf' if we don't use the existing 
  'sleep' commend, since we don't want to run a long-running 'perf' if we 
  can't set the death signal.

Good point. Added a note because prctl here should not return non-zero as the 
signal passed in is valid.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32694/#review78697
---


On April 1, 2015, 7:40 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32694/
 ---
 
 (Updated April 1, 2015, 7:40 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Set death signal for forked du processes for posix/disk isolator.
 
 
 Diffs
 -
 
   src/slave/containerizer/isolators/posix/disk.cpp 
 6e41e2a72cdcf914f2c922fdcb3d267b938e456e 
 
 Diff: https://reviews.apache.org/r/32694/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32653: Replace busy loop on ready file with a more relaxed loop

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32653/#review78666
---

Ship it!


Ship It!

- Jie Yu


On April 1, 2015, 11 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32653/
 ---
 
 (Updated April 1, 2015, 11 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Replace busy loop on ready file with a more relaxed loop
 
 
 Diffs
 -
 
   src/tests/port_mapping_tests.cpp f4124c3e880e043729579a829e1057727741d131 
 
 Diff: https://reviews.apache.org/r/32653/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Re: Review Request 32698: Used the argv version of subprocess for linux perf utilities.

[Jie Yu]

 On April 1, 2015, 10:38 p.m., Ben Mahler wrote:
  src/linux/perf.cpp, line 131
  https://reviews.apache.org/r/32698/diff/2/?file=912580#file912580line131
 
  Do you need the named 'argv' or can you return the initializer list 
  directly?

Yes, the following code does not compile on gcc-4.4:
```
return {
  ...
};
```

I can do
```
return vectorstring({
  ...
});
```


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32698/#review78612
---


On April 1, 2015, 7:40 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32698/
 ---
 
 (Updated April 1, 2015, 7:40 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Used the argv version of subprocess for linux perf utilities. See discussion 
 in MESOS-2462. This is to prepare for the death signal patch.
 
 
 Diffs
 -
 
   src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
 
 Diff: https://reviews.apache.org/r/32698/diff/
 
 
 Testing
 ---
 
 sudo make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32654: Clean up HostIPNetwork since every use performs the same extract stringify operation

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32654/#review78674
---

Ship it!



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32654/#comment127609

We usually put constructor/destructors after static methods.

```
public:
  static void SetUpTestCase()
  {
...
  }
  
  PortMappingIsolatorTest() : hostIP(net::IP(INADDR_ANY)) {}
```



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32654/#comment127613

hostIPNetwork.get().address() returns an net::IP, why do you need an extra 
copy constructor?

```
hostIP = hostIPNetwork.get().address();
```


- Jie Yu


On April 1, 2015, 11:07 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32654/
 ---
 
 (Updated April 1, 2015, 11:07 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Clean up HostIPNetwork since every use performs the same extract  stringify 
 operation
 
 
 Diffs
 -
 
   src/tests/port_mapping_tests.cpp f4124c3 
 
 Diff: https://reviews.apache.org/r/32654/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Re: Review Request 32744: PortMapping: change to not host namespace symlink handles in /var/run/netns.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32744/#review78669
---

Ship it!


This looks great! Just some nits!


src/slave/containerizer/isolators/network/port_mapping.hpp
https://reviews.apache.org/r/32744/#comment127581

Please put the `NOTE` in a new line.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127585

Kill this new line and add a new line above the `NOTE`.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127586

indent here should be 4 spaces.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127587

s/containerIDs/container IDs/

Here and everywhere else.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127588

Please print a warning here?
```
LOG(WARNING)  Detected non-symlink '  path
  ' under bind mount symlink root '
  PORT_MAPPING_BIND_MOUNT_SYMLINK_ROOT()
  '. Ignoring it;
 
```

Then, you don't need the comments above.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127590

Indent should be 4 spaces here.



src/slave/containerizer/isolators/network/port_mapping.cpp
https://reviews.apache.org/r/32744/#comment127591

Ditto.


- Jie Yu


On April 1, 2015, 10:36 p.m., Chi Zhang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32744/
 ---
 
 (Updated April 1, 2015, 10:36 p.m.)
 
 
 Review request for mesos, Jie Yu and Cong Wang.
 
 
 Bugs: mesos-2574
 https://issues.apache.org/jira/browse/mesos-2574
 
 
 Repository: mesos
 
 
 Description
 ---
 
 MESOS-2574
 
 
 Diffs
 -
 
   src/slave/containerizer/isolators/network/port_mapping.hpp 
 33837b4662959a003c8f38d1e786c6615287a4ff 
   src/slave/containerizer/isolators/network/port_mapping.cpp 
 e691d463515084518c94cdec3fbdf37be4a72977 
   src/tests/port_mapping_tests.cpp f4124c3e880e043729579a829e1057727741d131 
 
 Diff: https://reviews.apache.org/r/32744/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Chi Zhang
 

Re: Review Request 32699: Set death signal for the perf subprocess.

[Jie Yu]

 On April 2, 2015, 5:24 p.m., Ian Downes wrote:
  src/linux/perf.cpp, line 188
  https://reviews.apache.org/r/32699/diff/1/?file=911392#file911392line188
 
  I thought about this again, and it won't be sufficient for perf: we use 
  perf with a child sleep process to control the sample duration, e.g., perf 
  stat -a --event cycles -- sleep 123, and killing perf does not kill the 
  sleep process. I tested this in a shell so it may not be identical 
  behavior, but DEATHSIG is not preserved across a fork so it likely is the 
  same.
  
  {noformat}
  [idownes@hostname ~]$ sudo perf stat -a --event cycles -- sleep 123
  ... different shell ...
  [idownes@hostname ~]$ pgrep sleep | xargs ps
PID TTY  STAT   TIME COMMAND
  57461 pts/0S+ 0:00 sleep 123
  [idownes@hostname ~]$ sudo pkill perf
  [idownes@hostname ~]$ pgrep sleep | xargs ps
PID TTY  STAT   TIME COMMAND
  57461 pts/0S  0:00 sleep 123
  {noformat}
  
  This does not apply to the `du` usecase which is a single process.
  
  What *may* work for perf, but is not clearly documented in the prctl 
  manpage, is to run the processes in a process group and use -SIGKILL as the 
  DEATHSIG. Depending on how this was implemented, this might signal the 
  entire process group?

I checked the kernel code. This won't work. ::kill(-pid, SIGKILL) is the one 
that kill a process group (not ::kill(pid, -SIGKILL) :))


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32699/#review78678
---


On March 31, 2015, 8:14 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32699/
 ---
 
 (Updated March 31, 2015, 8:14 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Set death signal for the perf subprocess.
 
 
 Diffs
 -
 
   src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
 
 Diff: https://reviews.apache.org/r/32699/diff/
 
 
 Testing
 ---
 
 sudo make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32699: Set death signal for the perf subprocess.

[Jie Yu]

 On April 2, 2015, 5:24 p.m., Ian Downes wrote:
  src/linux/perf.cpp, line 188
  https://reviews.apache.org/r/32699/diff/1/?file=911392#file911392line188
 
  I thought about this again, and it won't be sufficient for perf: we use 
  perf with a child sleep process to control the sample duration, e.g., perf 
  stat -a --event cycles -- sleep 123, and killing perf does not kill the 
  sleep process. I tested this in a shell so it may not be identical 
  behavior, but DEATHSIG is not preserved across a fork so it likely is the 
  same.
  
  {noformat}
  [idownes@hostname ~]$ sudo perf stat -a --event cycles -- sleep 123
  ... different shell ...
  [idownes@hostname ~]$ pgrep sleep | xargs ps
PID TTY  STAT   TIME COMMAND
  57461 pts/0S+ 0:00 sleep 123
  [idownes@hostname ~]$ sudo pkill perf
  [idownes@hostname ~]$ pgrep sleep | xargs ps
PID TTY  STAT   TIME COMMAND
  57461 pts/0S  0:00 sleep 123
  {noformat}
  
  This does not apply to the `du` usecase which is a single process.
  
  What *may* work for perf, but is not clearly documented in the prctl 
  manpage, is to run the processes in a process group and use -SIGKILL as the 
  DEATHSIG. Depending on how this was implemented, this might signal the 
  entire process group?
 
 Jie Yu wrote:
 I checked the kernel code. This won't work. ::kill(-pid, SIGKILL) is the 
 one that kill a process group (not ::kill(pid, -SIGKILL) :))

I created https://issues.apache.org/jira/browse/MESOS-2590

Looks like the additional sleep process is not strictly needed.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32699/#review78678
---


On March 31, 2015, 8:14 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32699/
 ---
 
 (Updated March 31, 2015, 8:14 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Set death signal for the perf subprocess.
 
 
 Diffs
 -
 
   src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
 
 Diff: https://reviews.apache.org/r/32699/diff/
 
 
 Testing
 ---
 
 sudo make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32728: Fixed indentation in mesos.proto.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32728/#review78543
---

Ship it!


Thanks!

- Jie Yu


On April 1, 2015, 5:16 p.m., Chi Zhang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32728/
 ---
 
 (Updated April 1, 2015, 5:16 p.m.)
 
 
 Review request for mesos and Jie Yu.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed indentation in mesos.proto.
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 0cbee3b188c2f55f6da16d064e1ae9266832d35b 
 
 Diff: https://reviews.apache.org/r/32728/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Chi Zhang
 

Re: Review Request 32694: Set death signal for forked du processes for posix/disk isolator.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32694/
---

(Updated April 1, 2015, 7:40 p.m.)


Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Changes
---

Review comments.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Set death signal for forked du processes for posix/disk isolator.


Diffs (updated)
-

  src/slave/containerizer/isolators/posix/disk.cpp 
6e41e2a72cdcf914f2c922fdcb3d267b938e456e 

Diff: https://reviews.apache.org/r/32694/diff/


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 32698: Used the argv version of subprocess for linux perf utilities.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32698/
---

(Updated April 1, 2015, 7:40 p.m.)


Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Changes
---

Review comments.


Bugs: MESOS-2462
https://issues.apache.org/jira/browse/MESOS-2462


Repository: mesos


Description
---

Used the argv version of subprocess for linux perf utilities. See discussion in 
MESOS-2462. This is to prepare for the death signal patch.


Diffs (updated)
-

  src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 

Diff: https://reviews.apache.org/r/32698/diff/


Testing
---

sudo make check


Thanks,

Jie Yu

Re: Review Request 32694: Set death signal for forked du processes for posix/disk isolator.

[Jie Yu]

 On April 1, 2015, 3:32 p.m., James Peach wrote:
  src/slave/containerizer/isolators/posix/disk.cpp, line 21
  https://reviews.apache.org/r/32694/diff/2/?file=911373#file911373line21
 
  Rather than depending on ``__linux__``, consider adding ``sys/prctl.h`` 
  to ``AC_CHECK_HEADERS`` and using ``#if HAVE_SYS_PRCTL_H``.

I searched our code base. We never used `#if HAVE_SOME_HEADER_H` in our code 
base. I also feels like we should avoid doing that so that our code does not 
have a dependency to autoconf (we may change that in the future, say, using 
CMake, bazel, etc.)


 On April 1, 2015, 3:32 p.m., James Peach wrote:
  src/slave/containerizer/isolators/posix/disk.cpp, line 363
  https://reviews.apache.org/r/32694/diff/2/?file=911373#file911373line363
 
  A minor nitpick, but I think that ``#ifdef PR_SET_PDEATHSIG`` would be 
  better than ``#ifdef __linux__`` since other platforms may implement this 
  prctl() in the future.

We have `#ifdef __linux__ #include sys/prctl.h #endif` for includes, I prefer 
keeping it the same here:) Thanks for the suggestion anyway!


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32694/#review78526
---


On March 31, 2015, 7:32 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32694/
 ---
 
 (Updated March 31, 2015, 7:32 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Set death signal for forked du processes for posix/disk isolator.
 
 
 Diffs
 -
 
   src/slave/containerizer/isolators/posix/disk.cpp 
 6e41e2a72cdcf914f2c922fdcb3d267b938e456e 
 
 Diff: https://reviews.apache.org/r/32694/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32694: Set death signal for forked du processes for posix/disk isolator.

[Jie Yu]

 On April 1, 2015, 12:55 a.m., Ben Mahler wrote:
  src/slave/containerizer/isolators/posix/disk.cpp, lines 416-419
  https://reviews.apache.org/r/32694/diff/2/?file=911373#file911373line416
 
  Can't you just bind directly into `prctl`?
  
  E.g.
  
  ```
  Optionlambda::functionint() setup = None();
  
  #ifdef __linux__
  setup = lambda::bind(::prctl(PR_SET_PDEATHSIG, SIGKILL));
  #endif
  
  TrySubprocess s = subprocess(
  du,
  argv,
  Subprocess::PATH(/dev/null),
  Subprocess::PIPE(),
  Subprocess::PIPE(),
  None(),
  None(),
  setup);
  ```

This has slightly different semantics because if prctl fails, the subprocess 
won't be exec'ed. I want to make it a best effort semantics. I liked the idea 
of using lambda here. I tried to use an anonymous struct functor here. But it 
does not work on gcc-4.4.


- Jie


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32694/#review78457
---


On March 31, 2015, 7:32 p.m., Jie Yu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32694/
 ---
 
 (Updated March 31, 2015, 7:32 p.m.)
 
 
 Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.
 
 
 Bugs: MESOS-2462
 https://issues.apache.org/jira/browse/MESOS-2462
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Set death signal for forked du processes for posix/disk isolator.
 
 
 Diffs
 -
 
   src/slave/containerizer/isolators/posix/disk.cpp 
 6e41e2a72cdcf914f2c922fdcb3d267b938e456e 
 
 Diff: https://reviews.apache.org/r/32694/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Jie Yu
 

Re: Review Request 32654: Clean up HostIPNetwork since every use performs the same extract stringify operation

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32654/#review78585
---


The diff does seem to be correct.

- Jie Yu


On April 1, 2015, 8:42 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32654/
 ---
 
 (Updated April 1, 2015, 8:42 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Clean up HostIPNetwork since every use performs the same extract  stringify 
 operation
 
 
 Diffs
 -
 
   src/tests/port_mapping_tests.cpp f4124c3e880e043729579a829e1057727741d131 
 
 Diff: https://reviews.apache.org/r/32654/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett
 

Review Request 32742: Added command logging for processes running in slave's cgroup.

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32742/
---

Review request for mesos, Ben Mahler, Ian Downes, and Vinod Kone.


Bugs: MESOS-2461
https://issues.apache.org/jira/browse/MESOS-2461


Repository: mesos


Description
---

Added command logging for processes running in slave's cgroup.


Diffs
-

  src/slave/slave.cpp 0f70ebafb0f5b16c560decc66e22a43a52732d09 

Diff: https://reviews.apache.org/r/32742/diff/


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 32653: Replace busy look on ready file with a more relaxed loop

[Jie Yu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32653/#review78605
---



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127506

Kill this extra line.



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127519

TODO(pbrett): Consider generalizing this function and moving it to a common 
header.



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127505

static bool waitForFileCreation



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127511

s/timeout/duration/

since we have process::Timeout (Clock aware), it's better to avoid 
confusion here.



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127507

60seconds might be too long. Probably change it to 15 seconds so that it's 
consistent with AWAIT_READY default.



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127520

Please include stout/stopwatch.hpp



src/tests/port_mapping_tests.cpp
https://reviews.apache.org/r/32653/#comment127512

s/Seconds(0)/Duration::zero()/


- Jie Yu


On April 1, 2015, 8:54 p.m., Paul Brett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32653/
 ---
 
 (Updated April 1, 2015, 8:54 p.m.)
 
 
 Review request for mesos, Chi Zhang, Ian Downes, and Cong Wang.
 
 
 Bugs: mesos-2332
 https://issues.apache.org/jira/browse/mesos-2332
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Replace busy look on ready file with a more relaxed loop
 
 
 Diffs
 -
 
   src/tests/port_mapping_tests.cpp f4124c3e880e043729579a829e1057727741d131 
 
 Diff: https://reviews.apache.org/r/32653/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Paul Brett