Re: [VOTE] Release Apache Mesos 0.26.1 (rc2)

[Benjamin Mahler]

Also, I tagged https://issues.apache.org/jira/browse/MESOS-5021 with a fix
version of 0.26.1. Can you include it?

On Mon, Mar 21, 2016 at 1:59 PM, Benjamin Mahler  wrote:

> Yes it has existed for a long time but has only been discovered recently.
>
> The way this was discovered was that garbage collection of user sandboxes
> fails, which can result in the disk eventually filling up. This occurs when
> there are special files in the sandbox (e.g. socket file).
>
> IMO it's a critical issue to fix.
>
> On Sat, Mar 19, 2016 at 6:39 AM, Michael Park  wrote:
>
>> Ben,
>>
>> Do I understand correctly that this is not a regression, but a fix
>> important enough for us to backport?
>> I'm curious as to what makes it significant. Could you elaborate a little
>> as to what the consequences are?
>>
>> Thanks!
>>
>> MPark
>>
>> On 18 March 2016 at 16:20, Benjamin Mahler  wrote:
>>
>>> These are be captured under:
>>> https://issues.apache.org/jira/browse/MESOS-4979
>>>
>>> On Thu, Mar 17, 2016 at 5:04 PM, Benjamin Mahler 
>>> wrote:
>>>
 Thanks for the hard work! Do we need to backport the rmdir fixes on the
 outstanding release candidates?

 commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
 Author: Jojy Varghese 
 Date:   Tue Mar 15 17:12:01 2016 -0700

 Added support for FTS_SLNONE in rmdir.

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

 commit fbe1f37f65fd9f1d4f2c30a3cfd7a50df92ccc2c
 Author: Alex Clemmer 
 Date:   Tue Mar 1 23:29:21 2016 -0800

 Stout:[1/2] Fixed error reporting bug in `os::rmdir`.

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

 commit f8b7ac28b1a918864a06b3f99f45b0257c7b6f68
 Author: Jojy Varghese 
 Date:   Tue Mar 1 14:32:13 2016 -0800

 Added FS_DEFAULT case in rmdir.

 We currently dont handle special files like device files in rmdir.
 This
 change adds FS_DEFAULT as one of the cases where we try to unlink a
 file. Reference: http://man7.org/linux/man-pages/man3/fts.3.html

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

 On Wed, Mar 16, 2016 at 8:21 PM, Vinod Kone 
 wrote:

> +1 (binding)
>
> Tested on ASF CI.
>
> On Sun, Mar 13, 2016 at 4:33 PM, Michael Park 
> wrote:
>
> > +1 (binding)
> >
> > Internal CI results with the corresponding JIRA tickets for the
> failed
> > tests:
> >
> > CentOS 6 (non-SSL):
> >   - MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
> > (MESOS-3049 )
> >   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> > (MESOS-4039 )
> >   - UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup
> > (MESOS-4035 )
> >   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
> > (MESOS-3215 )
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> > (MESOS-4047 ,
> > MESOS-4053 )
> >
> > CentOS 6 (SSL):
> >   - MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
> > (MESOS-3049 )
> >   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> > (MESOS-4039 )
> >   - UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup
> > (MESOS-4035 )
> >   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
> > (MESOS-3215 )
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> > (MESOS-4047 ,
> > MESOS-4053 )
> >
> > CentOS 7 (non-SSL):
> >   - LimitedCpuIsolatorTest.ROOT_CGROUPS_Pids_and_Tids
> > (MESOS-4677 )
> >   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> > (MESOS-4039 )
> >   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
> > (MESOS-3215 )
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> > (MESOS-4047 

Re: [VOTE] Release Apache Mesos 0.25.1 (rc2)

[Benjamin Mahler]

Also, I tagged https://issues.apache.org/jira/browse/MESOS-5021 with a fix
version of 0.25.1. Can you include it?

On Sat, Mar 19, 2016 at 6:33 AM, Michael Park  wrote:

> As there are insufficient votes on this rc along with a request
> from Evan Krall to include additional fixes:
> https://www.mail-archive.com/user@mesos.apache.org/msg06204.html
> ,
> I'm declaring this rc failed, and will cut be cutting an rc3 early next
> week.
>
> Thanks,
>
> MPark
>
> On 13 March 2016 at 19:55, Michael Park  wrote:
>
>> +1 (binding)
>>
>> Internal CI results with the corresponding JIRA tickets for the failed
>> tests:
>>
>> CentOS 6 (non-SSL):
>> CentOS 6 (SSL):
>>   - Failed with MESOS-2017
>> 
>>
>> CentOS 7 (non-SSL):
>>   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
>> (MESOS-4039 )
>>   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
>> (MESOS-3215 )
>>   - LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromSandbox
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHost
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHostSandboxMountPoint
>>   - LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
>>   - LinuxFilesystemIsolatorTest.ROOT_SandboxEnvironmentVariable
>> (MESOS-3296 )
>>   - MesosContainerizerLaunchTest.ROOT_ChangeRootfs
>> (MESOS-3410 )
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>> (MESOS-4047 ,
>> MESOS-4053 )
>>
>> CentOS 7 (SSL):
>>   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
>> (MESOS-4039 )
>>   - ContainerizerTest.ROOT_CGROUPS_BalloonFramework
>> (MESOS-2672 )
>>   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
>> (MESOS-3215 )
>>   - LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromSandbox
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHost
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHostSandboxMountPoint
>>   - LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
>>   - LinuxFilesystemIsolatorTest.ROOT_SandboxEnvironmentVariable
>> (MESOS-3296 )
>>   - MesosContainerizerLaunchTest.ROOT_ChangeRootfs
>> (MESOS-3410 )
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>> (MESOS-4047 ,
>> MESOS-4053 )
>>
>> Debian 8 (non-SSL):
>> Debian 8 (SSL):
>>   - Failed with MESOS-3964
>> 
>>
>> Ubuntu 12 (non-SSL):
>>   - DockerContainerizerTest.ROOT_DOCKER_Logs
>> (MESOS-4676 )
>>   - UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
>>   - UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
>> (MESOS-4035 )
>>
>> Ubuntu 12 (SSL):
>>   - UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
>>   - UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
>> (MESOS-4035 )
>>   - ContainerizerTest.ROOT_CGROUPS_BalloonFramework
>> (MESOS-2672 )
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>> (MESOS-4047 ,
>> MESOS-4053 )
>>
>> Ubuntu 14 (non-SSL):
>>   - UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
>>   - UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
>> (MESOS-4035 )
>>
>> Ubuntu 14 (SSL):
>>   - UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
>>   - UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
>> (MESOS-4035 )
>>   - ContainerizerTest.ROOT_CGROUPS_BalloonFramework
>> (MESOS-2672 

Re: [VOTE] Release Apache Mesos 0.24.2 (rc2)

[Benjamin Mahler]

Also, I tagged https://issues.apache.org/jira/browse/MESOS-5021 with a fix
version of 0.24.2. Can you include it?

On Sat, Mar 19, 2016 at 6:30 AM, Michael Park  wrote:

> As there are insufficient votes on this rc along with a request
> from Evan Krall to include additional fixes:
> https://www.mail-archive.com/user@mesos.apache.org/msg06205.html,
> I'm declaring this rc failed, and will cut be cutting an rc3 early next
> week.
>
> Thanks,
>
> MPark
>
> On 13 March 2016 at 20:57, Michael Park  wrote:
>
>> +1 (binding)
>>
>> Internal CI results with the corresponding JIRA tickets for the failed
>> tests:
>>
>> CentOS 6 (non-SSL):
>> CentOS 6 (SSL):
>>   - Failed with MESOS-2017
>> 
>>
>> CentOS 7 (non-SSL):
>> CentOS 7 (SSL):
>>   - PerfEventIsolatorTest.ROOT_CGROUPS_Sample
>> (MESOS-4039 )
>>   - CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
>> (MESOS-3215 )
>>   - LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromSandbox
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHost
>>   - LinuxFilesystemIsolatorTest.ROOT_VolumeFromHostSandboxMountPoint
>>   - LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithRootFilesystem
>> (MESOS-3296 )
>>   - MesosContainerizerLaunchTest.ROOT_ChangeRootfs
>> (MESOS-3410 )
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
>>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>> (MESOS-4047 ,
>> MESOS-4053 )
>>   - PerfTest.ROOT_SamplePid
>> (MESOS-3079 )
>>
>> Debian 8 (non-SSL):
>> Debian 8 (SSL):
>>   - Failed with MESOS-3964
>> 
>>
>> Ubuntu 12 (non-SSL):
>> Ubuntu 12 (SSL):
>> Ubuntu 14 (non-SSL):
>> Ubuntu 14 (SSL):
>>   - UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
>>   - UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
>> (MESOS-4035 )
>>
>> Ubuntu 15 (non-SSL):
>>   - DockerContainerizerTest.ROOT_DOCKER_Logs
>> (MESOS-4676 )
>>   - LimitedCpuIsolatorTest.ROOT_CGROUPS_Pids_and_Tids
>> (MESOS-4677 )
>>
>> Ubuntu 15 (SSL): Success!
>>
>> On 13 March 2016 at 18:42, Michael Park  wrote:
>>
>>> While the vote for this release was open until Fri Mar 11 23:59:59 EST
>>> 2016,
>>> I'm going to give it another 3 days since there has not been any -1
>>> votes.
>>>
>>> The vote is extended until Wed Mar 16 23:59:59 EST 2016.
>>>
>>> On 10 March 2016 at 12:49, Greg Mann  wrote:
>>>
 +1 (non-binding)

 Ran `sudo make check` on CentOS 7, using gcc with libevent and SSL
 enabled. All tests pass.

 I was also able to successfully test a simple upgrade scenario from
 0.23.1 to 0.24.2-rc2 using the script found here:
 https://reviews.apache.org/r/44229/

 Cheers,
 Greg


 On Tue, Mar 8, 2016 at 6:50 PM, Michael Park  wrote:

> The link to the commit above points to the one on the master branch.
> The following is the one on the `0.24.2-rc2` branch: Fixed compiler
> warning
> in values tests.
> <
> https://github.com/apache/mesos/commit/afb8a0cffaf8bc235ce45087c80bafe87488dcd0
> >
>
> On 8 March 2016 at 21:21, Michael Park  wrote:
>
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos
> 0.24.2.
> >
> >
> > 0.24.2 includes the following:
> >
> >
> 
> >
> > The only diff with RC1 is the following: Fixed compiler warning in
> values
> > tests.
> > <
> https://github.com/apache/mesos/commit/bfeb070a2aef52f445eb057076d344fd184eb461
> >
>
> > As I described in the RC1 [VOTE] thread, even though this is a
> trivial
> > compile fix,
> > I decided to cut an RC2 in order to avoid breaking those who compile
> Mesos
> > from source.
> >
> > * Improvements
> > - Allocator filter performance
> > - Port Ranges performance
> > - UUID performance
> > - `/state` endpoint performance
> >   - GLOG performance
> >   - Configurable task/framework history
> >   - Offer filter timeout fix for backlogged allocator
> >
> > * Bugs
> >   - SSL
> >   - Libevent
> >   - Fixed point resources math
> >   - HDFS
> >   - Agent upgrade 

Re: 0.28.1

[Benjamin Mahler]

Thanks Jie, I've added a fix version of 0.28.1 to:
https://issues.apache.org/jira/browse/MESOS-5021

On Fri, Mar 18, 2016 at 5:52 PM, Jie Yu  wrote:

> 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: How to make full version available in /version endpoint

[Jeff Schroeder]

Correct. That is what I was suggesting you do.

On Wednesday, March 23, 2016, Zhitao Li  wrote:

> Erik, that would still be a problem if an organization is building Mesos
> between release versions.
>
> Jeff/Vinod, it seems like the 0.26.0 part comes from this line:
>
> AC_INIT([mesos], [0.29.0])
>
> and it's possible to patch that line to allow a custom version (read from
> a file or variable using m4_esyscmd_s).
>
>
>
> On Wed, Mar 23, 2016 at 5:24 PM, Erik Weathers  > wrote:
>
>> The extra "-2.0.16" portion of that version number is an artifact from
>> Mesosphere's build system, and my understanding is they are going to get
>> rid of it.  So perhaps this will not be a problem in the future?
>>
>> - Erik
>>
>> On Wed, Mar 23, 2016 at 5:10 PM, Jeff Schroeder <
>> jeffschroe...@computer.org
>> > wrote:
>>
>>> Perhaps building your own version, with your own version string would be
>>> sufficient? A general purpose feature to override the stated version with
>>> an environment variable doesn't seem very applicable in many environments.
>>> Perhaps there is a different way you could accomplish the same ultimate
>>> goal?
>>>
>>>
>>> On Wednesday, March 23, 2016, Zhitao Li >> > wrote:
>>>
 We want to have an external system to monitor or manage the full Mesos
 cluster, and neither the current "version" nor git_sha seems sufficient to
 determine whether a build being run is what we needed, especially when we
 move to our own packages.

 Being able to override the "version" key with an environment variable
 is probably sufficient for us.

 On Wed, Mar 23, 2016 at 4:51 PM, Vinod Kone 
 wrote:

> Not currently, no. What's your use case?
>
> On Wed, Mar 23, 2016 at 3:50 PM, Zhitao Li 
> wrote:
>
>> Hi,
>>
>> Has anyone brought up the possibility of making the full version
>> (i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?
>>
>> For example, when we are using the mesosphere community package, we
>> want '0.27.1-2.0.226.debian81' string show up, but we only get the
>> following right now:
>>
>> {
>>   "build_date": "2016-02-23 00:39:17",
>>   "build_time": 1456187957,
>>   "build_user": "root",
>>   "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
>>   "git_tag": "0.27.1",
>>   "version": "0.27.1"
>> }
>>
>> Is there an environment variable or something which we could tweak at
>> build/package time to get it? Thanks!
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>


 --
 Cheers,

 Zhitao Li

>>>
>>>
>>> --
>>> Text by Jeff, typos by iPhone
>>>
>>
>>
>
>
> --
> Cheers,
>
> Zhitao Li
>


-- 
Text by Jeff, typos by iPhone

Re: How to make full version available in /version endpoint

[Zhitao Li]

Erik, that would still be a problem if an organization is building Mesos
between release versions.

Jeff/Vinod, it seems like the 0.26.0 part comes from this line:

AC_INIT([mesos], [0.29.0])

and it's possible to patch that line to allow a custom version (read from a
file or variable using m4_esyscmd_s).



On Wed, Mar 23, 2016 at 5:24 PM, Erik Weathers 
wrote:

> The extra "-2.0.16" portion of that version number is an artifact from
> Mesosphere's build system, and my understanding is they are going to get
> rid of it.  So perhaps this will not be a problem in the future?
>
> - Erik
>
> On Wed, Mar 23, 2016 at 5:10 PM, Jeff Schroeder <
> jeffschroe...@computer.org> wrote:
>
>> Perhaps building your own version, with your own version string would be
>> sufficient? A general purpose feature to override the stated version with
>> an environment variable doesn't seem very applicable in many environments.
>> Perhaps there is a different way you could accomplish the same ultimate
>> goal?
>>
>>
>> On Wednesday, March 23, 2016, Zhitao Li  wrote:
>>
>>> We want to have an external system to monitor or manage the full Mesos
>>> cluster, and neither the current "version" nor git_sha seems sufficient to
>>> determine whether a build being run is what we needed, especially when we
>>> move to our own packages.
>>>
>>> Being able to override the "version" key with an environment variable is
>>> probably sufficient for us.
>>>
>>> On Wed, Mar 23, 2016 at 4:51 PM, Vinod Kone 
>>> wrote:
>>>
 Not currently, no. What's your use case?

 On Wed, Mar 23, 2016 at 3:50 PM, Zhitao Li 
 wrote:

> Hi,
>
> Has anyone brought up the possibility of making the full version
> (i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?
>
> For example, when we are using the mesosphere community package, we
> want '0.27.1-2.0.226.debian81' string show up, but we only get the
> following right now:
>
> {
>   "build_date": "2016-02-23 00:39:17",
>   "build_time": 1456187957,
>   "build_user": "root",
>   "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
>   "git_tag": "0.27.1",
>   "version": "0.27.1"
> }
>
> Is there an environment variable or something which we could tweak at
> build/package time to get it? Thanks!
>
> --
> Cheers,
>
> Zhitao Li
>


>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>


-- 
Cheers,

Zhitao Li

Re: How to make full version available in /version endpoint

[Jeff Schroeder]

Perhaps building your own version, with your own version string would be
sufficient? A general purpose feature to override the stated version with
an environment variable doesn't seem very applicable in many environments.
Perhaps there is a different way you could accomplish the same ultimate
goal?

On Wednesday, March 23, 2016, Zhitao Li  wrote:

> We want to have an external system to monitor or manage the full Mesos
> cluster, and neither the current "version" nor git_sha seems sufficient to
> determine whether a build being run is what we needed, especially when we
> move to our own packages.
>
> Being able to override the "version" key with an environment variable is
> probably sufficient for us.
>
> On Wed, Mar 23, 2016 at 4:51 PM, Vinod Kone  > wrote:
>
>> Not currently, no. What's your use case?
>>
>> On Wed, Mar 23, 2016 at 3:50 PM, Zhitao Li > > wrote:
>>
>>> Hi,
>>>
>>> Has anyone brought up the possibility of making the full version
>>> (i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?
>>>
>>> For example, when we are using the mesosphere community package, we want 
>>> '0.27.1-2.0.226.debian81'
>>> string show up, but we only get the following right now:
>>>
>>> {
>>>   "build_date": "2016-02-23 00:39:17",
>>>   "build_time": 1456187957,
>>>   "build_user": "root",
>>>   "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
>>>   "git_tag": "0.27.1",
>>>   "version": "0.27.1"
>>> }
>>>
>>> Is there an environment variable or something which we could tweak at
>>> build/package time to get it? Thanks!
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>
>
> --
> Cheers,
>
> Zhitao Li
>


-- 
Text by Jeff, typos by iPhone

Re: How to make full version available in /version endpoint

[Vinod Kone]

Not currently, no. What's your use case?

On Wed, Mar 23, 2016 at 3:50 PM, Zhitao Li  wrote:

> Hi,
>
> Has anyone brought up the possibility of making the full version
> (i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?
>
> For example, when we are using the mesosphere community package, we want 
> '0.27.1-2.0.226.debian81'
> string show up, but we only get the following right now:
>
> {
>   "build_date": "2016-02-23 00:39:17",
>   "build_time": 1456187957,
>   "build_user": "root",
>   "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
>   "git_tag": "0.27.1",
>   "version": "0.27.1"
> }
>
> Is there an environment variable or something which we could tweak at
> build/package time to get it? Thanks!
>
> --
> Cheers,
>
> Zhitao Li
>

How to make full version available in /version endpoint

[Zhitao Li]

Hi,

Has anyone brought up the possibility of making the full version
(i.e. 0.28.0-2.0.16.debian81a) show up in the the /version endpoint?

For example, when we are using the mesosphere community package, we
want '0.27.1-2.0.226.debian81'
string show up, but we only get the following right now:

{
  "build_date": "2016-02-23 00:39:17",
  "build_time": 1456187957,
  "build_user": "root",
  "git_sha": "864fe8eabd4a83b78ce9140c501908ee3cb90beb",
  "git_tag": "0.27.1",
  "version": "0.27.1"
}

Is there an environment variable or something which we could tweak at
build/package time to get it? Thanks!

-- 
Cheers,

Zhitao Li

Re: limit swap usage with docker containeriser

[haosdent]

Yes, this flag only available in mesos containerizer.

On Wed, Mar 23, 2016 at 10:11 PM, David Keijser 
wrote:

> On Wed, Mar 23, 2016 at 09:42:50PM +0800, haosdent wrote:
> > Do you mean add `memory-swap` when start docker container in Mesos? There
> > is a field `repeated Parameter parameters = 5;` in DockerInfo proto. You
> > could pass your docker running parameters in this field.
>
> What I'm looking for is a flag (like `cgroups_limit_swap`) to always
> enable limits on both memory and swap based on the resources allocated.
> Without the need for every framework to add the memory-swap docker
> option to each task.
>



-- 
Best Regards,
Haosdent Huang

Re: limit swap usage with docker containeriser

[David Keijser]

On Wed, Mar 23, 2016 at 09:42:50PM +0800, haosdent wrote:
> Do you mean add `memory-swap` when start docker container in Mesos? There
> is a field `repeated Parameter parameters = 5;` in DockerInfo proto. You
> could pass your docker running parameters in this field.

What I'm looking for is a flag (like `cgroups_limit_swap`) to always
enable limits on both memory and swap based on the resources allocated.
Without the need for every framework to add the memory-swap docker
option to each task.


signature.asc
Description: PGP signature

limit swap usage with docker containeriser

[David Keijser]

Hi

I'm looking for a way of limiting the swap usage of tasks running as
docker containers. My use case is exactly the same as in MESOS-1662 but
the flag introduced to fix that does not apply to docker from what I can
tell.

Setting a custom docker flag to limit total memory to be the same as the
memory resource is a possible work around but doing that puts the
Responsibility to of keeping the values in sync on the one running tasks
through e.g marathon and not on the operator of the cluster.

Any ideas? How hard would it be to change so that flag also applies for
docker?


signature.asc
Description: PGP signature

Re: About executor failover

[琪 冯]

I should say finally I found a way to clean orphans containers.
I learnt the executor will not remove its container when the task complete. 
Executor will stop the container and exit. The container will in exit state and 
stay in the slave machine until --docker_remove_delay.
I set --docker_remove_delay="1mins", and restarted the slave, and killed an 
executor process. After 1 minute, the container left by the killed executor 
removed.
This may not be a good way to solve my problem. But it do.
Thank you haosdent. Thank you for your help. []



From: haosdent 
Sent: Wednesday, March 23, 2016 11:17 AM
To: user
Subject: Re: About executor failover

But I think we could make sure docker container exit when kill executor. If you 
have clear requirements, could you fill it in 
https://issues.apache.org/jira/browse/MESOS So other folks could help check 
whether it should be accepted or not.
[https://issues.apache.org/jira/secure/projectavatar?pid=12311242=17056=large]

Mesos - ASF JIRA - 
issues.apache.org
issues.apache.org
A list of upcoming versions. Click on the row to display issues for that 
version.



On Wed, Mar 23, 2016 at 7:14 PM, haosdent 
> wrote:
As I know, could not know orphan containers in framework now.

On Wed, Mar 23, 2016 at 6:50 PM, 琪 冯 
> wrote:


Many thanks for reply!
I learnt the orphans containers were removed by the slave recovery. I mean, is 
there anything I can do from the framework, or some other monitors to remove or 
detect them automatically.

Thanks for your helps.



From: haosdent >
Sent: Wednesday, March 23, 2016 3:22 AM
To: user
Subject: Re: About executor failover

Yes, in that case, these orphans containers would be recovered or killed when 
you restart slave.

On Wed, Mar 23, 2016 at 11:13 AM, ? ? 
> wrote:

What if the executor process down with its docker container still alive?

As I tested, I killed an executor process in one of my mesos slave machines, 
the process detail just like:


root 17166  9569  0 Mar22 ?00:01:39 mesos-docker-executor 
--container=mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa
 --docker=docker --docker_socket=/var/run/docker.sock --help=false 
--mapped_directory=/mnt/mesos/sandbox 
--sandbox_directory=/data/mesos/slaves/0d58cb85-e726-479a-a57a-83405e3ae580-S3/frameworks/5cfc9845-05c0-45b1-acc0-595ab92075d2-/executors/archtools_hearthstone.eless_eless.uwsgi.353f920b-eff6-11e5-97d3-aeb4726ea116/runs/b995031b-9c46-4713-9050-518aa306c6aa
 --stop_timeout=0ns



The I checked the container with name 
"mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa"
 was still alive.


My mesos version is 0.25.0. And the mesos slave machine kernel version is Linux 
3.10.0-229.11.1.el7.x86_64.


I mean if executor process crashed/killed for whatever reasons(but the 
container is alive), a new container will launch for the task_lost event. So a 
container created by the dead executor process would be undiscoverable to my 
framework.


I want to know if I am wrong, or there is a way to handle this scenario.


I hope my question is clear, if not, please let me know.


Any feedback would be appreciated. []




--
Best Regards,
Haosdent Huang



--
Best Regards,
Haosdent Huang



--
Best Regards,
Haosdent Huang

Re: About executor failover

[haosdent]

But I think we could make sure docker container exit when kill executor. If
you have clear requirements, could you fill it in
https://issues.apache.org/jira/browse/MESOS So other folks could help check
whether it should be accepted or not.

On Wed, Mar 23, 2016 at 7:14 PM, haosdent  wrote:

> As I know, could not know orphan containers in framework now.
>
> On Wed, Mar 23, 2016 at 6:50 PM, 琪 冯  wrote:
>
>>
>> Many thanks for reply!
>> I learnt the orphans containers were removed by the slave recovery. I
>> mean, is there anything I can do from the framework, or some other monitors
>> to remove or detect them automatically.
>>
>> Thanks for your helps.
>>
>>
>> --
>> *From:* haosdent 
>> *Sent:* Wednesday, March 23, 2016 3:22 AM
>> *To:* user
>> *Subject:* Re: About executor failover
>>
>> Yes, in that case, these orphans containers would be recovered or killed
>> when you restart slave.
>>
>> On Wed, Mar 23, 2016 at 11:13 AM, ? ?  wrote:
>>
>>> What if the executor process down with its docker container still alive?
>>>
>>> As I tested, I killed an executor process in one of my mesos slave
>>> machines, the process detail just like:
>>>
>>>
>>> root 17166  9569  0 Mar22 ?00:01:39 mesos-docker-executor
>>> --container=mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa
>>> --docker=docker --docker_socket=/var/run/docker.sock --help=false
>>> --mapped_directory=/mnt/mesos/sandbox 
>>> --sandbox_directory=/data/mesos/slaves/0d58cb85-e726-479a-a57a-83405e3ae580-S3/frameworks/5cfc9845-05c0-45b1-acc0-595ab92075d2-/executors/archtools_hearthstone.eless_eless.uwsgi.353f920b-eff6-11e5-97d3-aeb4726ea116/runs/b995031b-9c46-4713-9050-518aa306c6aa
>>> --stop_timeout=0ns
>>>
>>>
>>> The I checked the container with name 
>>> "mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa"
>>> was still alive.
>>>
>>>
>>> My mesos version is 0.25.0. And the mesos slave machine kernel version
>>> is Linux 3.10.0-229.11.1.el7.x86_64.
>>>
>>>
>>> I mean if executor process crashed/killed for whatever reasons(but the
>>> container is alive), a new container will launch for the task_lost event.
>>> So a container created by the dead executor process would be undiscoverable
>>> to my framework.
>>>
>>>
>>> I want to know if I am wrong, or there is a way to handle this scenario.
>>>
>>>
>>> I hope my question is clear, if not, please let me know.
>>>
>>>
>>> Any feedback would be appreciated. [image: ]
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Best Regards,
Haosdent Huang

Re: About executor failover

[haosdent]

As I know, could not know orphan containers in framework now.

On Wed, Mar 23, 2016 at 6:50 PM, 琪 冯  wrote:

>
> Many thanks for reply!
> I learnt the orphans containers were removed by the slave recovery. I
> mean, is there anything I can do from the framework, or some other monitors
> to remove or detect them automatically.
>
> Thanks for your helps.
>
>
> --
> *From:* haosdent 
> *Sent:* Wednesday, March 23, 2016 3:22 AM
> *To:* user
> *Subject:* Re: About executor failover
>
> Yes, in that case, these orphans containers would be recovered or killed
> when you restart slave.
>
> On Wed, Mar 23, 2016 at 11:13 AM, ? ?  wrote:
>
>> What if the executor process down with its docker container still alive?
>>
>> As I tested, I killed an executor process in one of my mesos slave
>> machines, the process detail just like:
>>
>>
>> root 17166  9569  0 Mar22 ?00:01:39 mesos-docker-executor
>> --container=mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa
>> --docker=docker --docker_socket=/var/run/docker.sock --help=false
>> --mapped_directory=/mnt/mesos/sandbox 
>> --sandbox_directory=/data/mesos/slaves/0d58cb85-e726-479a-a57a-83405e3ae580-S3/frameworks/5cfc9845-05c0-45b1-acc0-595ab92075d2-/executors/archtools_hearthstone.eless_eless.uwsgi.353f920b-eff6-11e5-97d3-aeb4726ea116/runs/b995031b-9c46-4713-9050-518aa306c6aa
>> --stop_timeout=0ns
>>
>>
>> The I checked the container with name 
>> "mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa"
>> was still alive.
>>
>>
>> My mesos version is 0.25.0. And the mesos slave machine kernel version is
>> Linux 3.10.0-229.11.1.el7.x86_64.
>>
>>
>> I mean if executor process crashed/killed for whatever reasons(but the
>> container is alive), a new container will launch for the task_lost event.
>> So a container created by the dead executor process would be undiscoverable
>> to my framework.
>>
>>
>> I want to know if I am wrong, or there is a way to handle this scenario.
>>
>>
>> I hope my question is clear, if not, please let me know.
>>
>>
>> Any feedback would be appreciated. [image: ]
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Best Regards,
Haosdent Huang

Re: About executor failover

[琪 冯]

Many thanks for reply!
I learnt the orphans containers were removed by the slave recovery. I mean, is 
there anything I can do from the framework, or some other monitors to remove or 
detect them automatically.

Thanks for your helps.



From: haosdent 
Sent: Wednesday, March 23, 2016 3:22 AM
To: user
Subject: Re: About executor failover

Yes, in that case, these orphans containers would be recovered or killed when 
you restart slave.

On Wed, Mar 23, 2016 at 11:13 AM, ? ? 
> wrote:

What if the executor process down with its docker container still alive?

As I tested, I killed an executor process in one of my mesos slave machines, 
the process detail just like:


root 17166  9569  0 Mar22 ?00:01:39 mesos-docker-executor 
--container=mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa
 --docker=docker --docker_socket=/var/run/docker.sock --help=false 
--mapped_directory=/mnt/mesos/sandbox 
--sandbox_directory=/data/mesos/slaves/0d58cb85-e726-479a-a57a-83405e3ae580-S3/frameworks/5cfc9845-05c0-45b1-acc0-595ab92075d2-/executors/archtools_hearthstone.eless_eless.uwsgi.353f920b-eff6-11e5-97d3-aeb4726ea116/runs/b995031b-9c46-4713-9050-518aa306c6aa
 --stop_timeout=0ns



The I checked the container with name 
"mesos-0d58cb85-e726-479a-a57a-83405e3ae580-S3.b995031b-9c46-4713-9050-518aa306c6aa"
 was still alive.


My mesos version is 0.25.0. And the mesos slave machine kernel version is Linux 
3.10.0-229.11.1.el7.x86_64.


I mean if executor process crashed/killed for whatever reasons(but the 
container is alive), a new container will launch for the task_lost event. So a 
container created by the dead executor process would be undiscoverable to my 
framework.


I want to know if I am wrong, or there is a way to handle this scenario.


I hope my question is clear, if not, please let me know.


Any feedback would be appreciated. []




--
Best Regards,
Haosdent Huang

Re: xcode-mesos project is not working, anyone can do me a favor?

[tommy xiao]

Wooo

2016-03-23 9:19 GMT+08:00 haosdent :

> Hi, tommy. Maybe you could try [CLion](https://www.jetbrains.com/clion/)
> as your IDE.
>
> On Wed, Mar 23, 2016 at 8:26 AM, tommy xiao  wrote:
>
>> Issue
>> https://github.com/tillt/xcode-mesos/issues/3
>>
>> it seems not found the proto header. but i not found any issue in xocde
>> config
>>
>>
>> --
>> Deshi Xiao
>> Twitter: xds2000
>> E-mail: xiaods(AT)gmail.com
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com