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

[Gilbert Song]

Thank you guys. Should have been more careful to avoid this.

On Wed, Feb 3, 2016 at 9:17 PM, Jie Yu  wrote:

> Thanks James. Just committed a fix.
>
> On Wed, Feb 3, 2016 at 8:54 PM, James Peach  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 
> > > Authored: Wed Feb 3 17:14:23 2016 -0800
> > > Committer: Jie Yu 
> > > 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::create(
> > > {"cgroups/mem", &CgroupsMemIsolatorProcess::create},
> > > {"cgroups/net_cls", &CgroupsNetClsIsolatorProcess::create},
> > > {"cgroups/perf_event", &CgroupsPerfEventIsolatorProcess::create},
> > > +{"docker/runtime", &DockerRuntimeIsolatorProcess::create},
> > > {"namespaces/pid", &NamespacesPidIsolatorProcess::create},
> > > #endif
> > > #ifdef WITH_NETWORK_ISOLATOR
> > > @@ -839,7 +844,12 @@ Future>>
> > 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 DockerRuntimeIsolatorProcess::create(const Flags& flags)
> > > {
> > > -  return nullptr;
> > > +  process::Owned process(
> > > +  new DockerRuntimeIsolatorProcess(flags));
> > > +
> > > +  return new MesosIsolator(process);
> > > }
> > >
> > >
> > > @@ -64,7 +71,26 @@ Future>
> > 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.
> > > +re

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  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 
> > Authored: Wed Feb 3 17:14:23 2016 -0800
> > Committer: Jie Yu 
> > 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::create(
> > {"cgroups/mem", &CgroupsMemIsolatorProcess::create},
> > {"cgroups/net_cls", &CgroupsNetClsIsolatorProcess::create},
> > {"cgroups/perf_event", &CgroupsPerfEventIsolatorProcess::create},
> > +{"docker/runtime", &DockerRuntimeIsolatorProcess::create},
> > {"namespaces/pid", &NamespacesPidIsolatorProcess::create},
> > #endif
> > #ifdef WITH_NETWORK_ISOLATOR
> > @@ -839,7 +844,12 @@ Future>>
> 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 DockerRuntimeIsolatorProcess::create(const Flags& flags)
> > {
> > -  return nullptr;
> > +  process::Owned process(
> > +  new DockerRuntimeIsolatorProcess(flags));
> > +
> > +  return new MesosIsolator(process);
> > }
> >
> >
> > @@ -64,7 +71,26 @@ Future>
> 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: [3/3] mesos git commit: Plugged in docker runtime isolator.

[James Peach]

> 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 
> Authored: Wed Feb 3 17:14:23 2016 -0800
> Committer: Jie Yu 
> 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::create(
> {"cgroups/mem", &CgroupsMemIsolatorProcess::create},
> {"cgroups/net_cls", &CgroupsNetClsIsolatorProcess::create},
> {"cgroups/perf_event", &CgroupsPerfEventIsolatorProcess::create},
> +{"docker/runtime", &DockerRuntimeIsolatorProcess::create},
> {"namespaces/pid", &NamespacesPidIsolatorProcess::create},
> #endif
> #ifdef WITH_NETWORK_ISOLATOR
> @@ -839,7 +844,12 @@ Future>> 
> 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 DockerRuntimeIsolatorProcess::create(const Flags& flags)
> {
> -  return nullptr;
> +  process::Owned process(
> +  new DockerRuntimeIsolatorProcess(flags));
> +
> +  return new MesosIsolator(process);
> }
> 
> 
> @@ -64,7 +71,26 @@ Future> 
> 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: are mesos package version names predictable?

[tommy xiao]

sure.

2016-02-04 1:52 GMT+08:00 Erik Weathers :

> A. Thanks Tommy.  So I see that the Apache community doesn't release
> binary packages, just versioned source code tarballs:
>
>- https://mesos.apache.org/downloads/
>
> I'll follow up with Mesosphere directly, thanks!
>
> - Erik
>
> On Wednesday, February 3, 2016, tommy xiao  wrote:
>
> > it belong to mesosphere concerns, not apache community's scope.
> >
> > 2016-02-03 9:23 GMT+08:00 Erik Weathers :
> >
> > > I've noticed that in the published mesos packages [1] & docker images
> [2]
> > > that the version name isn't simply:
> > >
> > >-  mesos_0.27.0.ubuntu1404_amd64
> > >
> > > Instead it has the form of:
> > >
> > >- mesos_0.27.0*-0.2.190*.ubuntu1404_amd64
> > >
> > > Here are a few more examples of this numeric suffix:
> > >
> > >- 0.27.0 -> 0.27.0-0.2.190
> > >- 0.26.0 -> 0.26.0-0.2.145
> > >- 0.25.0 -> 0.25.0-0.2.70
> > >- 0.24.1 -> 0.24.1-0.2.35
> > >- 0.24.0 -> 0.24.0-1.0.27
> > >
> > > It is not clear to me what these suffixes represent, and it makes it
> hard
> > > to write code that can download or install the mesos package for a
> > > particular version given just the simple version name (e.g., 0.27.0).
> I
> > > tried searching for what might be generating this version suffix, or
> for
> > > documentation of the release process for mesos, but I have failed.
> > >
> > > So my question is really 2-fold:
> > > (1) Where does this extra suffix come from?  Does it represent
> something
> > > specific?  What is its purpose?   Why isn't the version simply the
> > version?
> > >  (I'm sure there *is* a reason, but I haven't found it on my own.)
> > > (2) What is the "right" way to handle this seeming unpredictability?
> > >
> > > Thanks!
> > >
> > > - Erik
> > >
> > > References:
> > > [1] http://open.mesosphere.com/downloads/mesos/
> > > [2] https://hub.docker.com/r/mesosphere/mesos/tags/
> > >
> >
> >
> >
> > --
> > Deshi Xiao
> > Twitter: xds2000
> > E-mail: xiaods(AT)gmail.com
> >
>



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

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

[Kapil Arya]

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
>> >
>
>

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

[Michael Park]

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
> >
>

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

[Benjamin Mahler]

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
>

Re: Contributor request

[Vinod Kone]

Done. Welcome!

On Wed, Feb 3, 2016 at 1:07 PM, Erik Weathers  wrote:

> Please add me as a contributor in the Mesos JIRA project.
> Apache JIRA username: erikdw
>
> Thanks!
>
> - Erik
>

Contributor request

[Erik Weathers]

Please add me as a contributor in the Mesos JIRA project.
Apache JIRA username: erikdw

Thanks!

- Erik

Re: Contributor request

[Vinod Kone]

Done. Welcome to the mesos community!

On Wed, Feb 3, 2016 at 11:25 AM, Michael Browning 
wrote:

> Hello,
>
> I'd like to be added as a Mesos contributor in JIRA, username "mrbrowning".
>
> Thank you,
> Michael
>

Contributor request

[Michael Browning]

Hello,

I'd like to be added as a Mesos contributor in JIRA, username "mrbrowning".

Thank you,
Michael

Re: are mesos package version names predictable?

[Erik Weathers]

A. Thanks Tommy.  So I see that the Apache community doesn't release
binary packages, just versioned source code tarballs:

   - https://mesos.apache.org/downloads/

I'll follow up with Mesosphere directly, thanks!

- Erik

On Wednesday, February 3, 2016, tommy xiao  wrote:

> it belong to mesosphere concerns, not apache community's scope.
>
> 2016-02-03 9:23 GMT+08:00 Erik Weathers :
>
> > I've noticed that in the published mesos packages [1] & docker images [2]
> > that the version name isn't simply:
> >
> >-  mesos_0.27.0.ubuntu1404_amd64
> >
> > Instead it has the form of:
> >
> >- mesos_0.27.0*-0.2.190*.ubuntu1404_amd64
> >
> > Here are a few more examples of this numeric suffix:
> >
> >- 0.27.0 -> 0.27.0-0.2.190
> >- 0.26.0 -> 0.26.0-0.2.145
> >- 0.25.0 -> 0.25.0-0.2.70
> >- 0.24.1 -> 0.24.1-0.2.35
> >- 0.24.0 -> 0.24.0-1.0.27
> >
> > It is not clear to me what these suffixes represent, and it makes it hard
> > to write code that can download or install the mesos package for a
> > particular version given just the simple version name (e.g., 0.27.0).  I
> > tried searching for what might be generating this version suffix, or for
> > documentation of the release process for mesos, but I have failed.
> >
> > So my question is really 2-fold:
> > (1) Where does this extra suffix come from?  Does it represent something
> > specific?  What is its purpose?   Why isn't the version simply the
> version?
> >  (I'm sure there *is* a reason, but I haven't found it on my own.)
> > (2) What is the "right" way to handle this seeming unpredictability?
> >
> > Thanks!
> >
> > - Erik
> >
> > References:
> > [1] http://open.mesosphere.com/downloads/mesos/
> > [2] https://hub.docker.com/r/mesosphere/mesos/tags/
> >
>
>
>
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com
>

Re: are mesos package version names predictable?

[tommy xiao]

it belong to mesosphere concerns, not apache community's scope.

2016-02-03 9:23 GMT+08:00 Erik Weathers :

> I've noticed that in the published mesos packages [1] & docker images [2]
> that the version name isn't simply:
>
>-  mesos_0.27.0.ubuntu1404_amd64
>
> Instead it has the form of:
>
>- mesos_0.27.0*-0.2.190*.ubuntu1404_amd64
>
> Here are a few more examples of this numeric suffix:
>
>- 0.27.0 -> 0.27.0-0.2.190
>- 0.26.0 -> 0.26.0-0.2.145
>- 0.25.0 -> 0.25.0-0.2.70
>- 0.24.1 -> 0.24.1-0.2.35
>- 0.24.0 -> 0.24.0-1.0.27
>
> It is not clear to me what these suffixes represent, and it makes it hard
> to write code that can download or install the mesos package for a
> particular version given just the simple version name (e.g., 0.27.0).  I
> tried searching for what might be generating this version suffix, or for
> documentation of the release process for mesos, but I have failed.
>
> So my question is really 2-fold:
> (1) Where does this extra suffix come from?  Does it represent something
> specific?  What is its purpose?   Why isn't the version simply the version?
>  (I'm sure there *is* a reason, but I haven't found it on my own.)
> (2) What is the "right" way to handle this seeming unpredictability?
>
> Thanks!
>
> - Erik
>
> References:
> [1] http://open.mesosphere.com/downloads/mesos/
> [2] https://hub.docker.com/r/mesosphere/mesos/tags/
>



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

Re: MESOS-4581 Docker containers getting stuck in staging.

[haosdent]

>Should Docker::inspect return to the caller on timeout, or follow a retry
system like it does with a non-zero exit code?
Yes, this depends how you implement your timeout logic in `after`. If you
discard future and return Failure in `after`, you would not continue the
future chain. But you also could retry in `after`. For example, because
here have already use `promise`(Another similar concept to Future). You
could retry that by
```
  Clock::timer(retryInterval.get(),
   [=]() { _inspect(cmd, promise, retryInterval); } );
```
as exist retry logic in `Docker::__inspect`.

>I still believe the initial delay is important
I think it is OK if we always fail without delay. After Docker fix this
problem, I think could remove this delay again.

Another suggestion is I think we should continue the implement discussion
in JIRA or reviewboard.


On Wed, Feb 3, 2016 at 11:40 PM, Hegner, Travis 
wrote:

> Thanks haosdent, that makes sense to allow the inspect command to time out
> on its own. Should Docker::inspect return to the caller on timeout, or
> follow a retry system like it does with a non-zero exit code? If the
> latter, should it retry forever if it times out every time?
>
> Are you suggesting this in addition to the patch I have introducing the
> delay so far? I still believe the initial delay is important, as without it
> we would encounter the docker inspect timeout very frequently in our
> environment.
>
> Thanks,
>
> Travis
>
> -Original Message-
> From: haosdent [mailto:haosd...@gmail.com]
> Sent: Wednesday, February 3, 2016 10:05 AM
> To: dev 
> Subject: Re: MESOS-4581 Docker containers getting stuck in staging.
>
> Hi, Hegner. I think Joly means we change Docker::inspect from ```
>   s.get().status()
> .onAny([=]() { __inspect(cmd, promise, retryInterval, output,
> s.get()); }); ``` to ```
>   s.get().status()
> .after(timeoutSeconds, []() {...})
> .onAny([=]() { __inspect(cmd, promise, retryInterval, output,
> s.get()); }); ```
>
> Suppose if 500ms not works in different environments, we still would go
> into same problem. I think add timeout limit in inspect would be better.
>
> On Wed, Feb 3, 2016 at 10:05 PM, Hegner, Travis 
> wrote:
>
> > Thanks Jojy,
> >
> > I agree that my current patch is not the most ideal solution, as it
> > was intended as a proof of concept to ensure that it was in fact the
> > timing that was causing the problems I've been experiencing. Perhaps I
> > didn't make that clear enough in the JIRA. That is also the reason I
> > haven't attempted to submit that patch back.
> >
> > I was hoping to open a dialog to discuss the most appropriate fix for
> > that error, as I am relatively new to the future/promise paradigm, and
> > I haven't done much in c++ in 10 years.
> >
> > I'm assuming that when you say "using 'after' on the future" you are
> > referring to the initial inspect call's future correct? In that case,
> > I'm not convinced that is the right solution either. If you dig into
> > the inspect call, you'll see that it has a fairly sophisticated retry
> > system itself. However, that retry system is designed around whether
> > the actual inspect command completes its execution. If the inspect
> > command runs forever, then that thread blocks waiting for it forever.
> >
> > I am leaning towards a combination of both. I believe that it is
> > appropriate to wait a small amount of time to call the initial
> > inspect, to give docker a chance to create and start the container. I
> > see your point in that there is still the possibility of a race
> > condition, if the run command is delayed for the right amount of time
> > itself, I understand that the run thread could be executed any time
> > after the future is created. When running the vanilla mesos (without
> > my current patch), remember that the containers that launch
> > successfully, actually do so because the initial inspect fails
> > (returns non 0 as the container doesn’t exist yet), and the inspect
> > function's built in retry system delays 500ms and runs again, this time
> successfully. (See these logs to see what I mean:
> > https://gist.github.com/travishegner/dcb5797f5a0919e45618)
> >
> > With that in mind, we wouldn't actually know whether the inspect is
> > just delayed in its own retry pattern, or is actually hung, unless we
> > wait a large enough amount of time. Given how frequently we encounter
> > this issue in our environment (more than half of the attempted
> > container launches), waiting a large amount of time to indicate
> > whether the container is running would be undesirable.
> >
> > How do you feel about an initial delay (how long 500ms?), in concert
> > with an ".after()" (how long 3000ms?) on the inspect future that will
> > discard the original inspect and try again? The initial delay would
> > give docker time to create and start our container, and in my
> > environment drastically reduce the frequency with which we are met
> > with this condition. Ir

Re: Contributor request

[Artem Harutyunyan]

Done. Welcome to the community!

On Wed, Feb 3, 2016 at 7:17 AM, Evers Benno  wrote:
> Hi,
>
> can you please add me as a contributor in JIRA? My username is "bennoe".
>
> Thanks,
> Benno

RE: MESOS-4581 Docker containers getting stuck in staging.

[Hegner, Travis]

Thanks haosdent, that makes sense to allow the inspect command to time out on 
its own. Should Docker::inspect return to the caller on timeout, or follow a 
retry system like it does with a non-zero exit code? If the latter, should it 
retry forever if it times out every time?

Are you suggesting this in addition to the patch I have introducing the delay 
so far? I still believe the initial delay is important, as without it we would 
encounter the docker inspect timeout very frequently in our environment.

Thanks,

Travis

-Original Message-
From: haosdent [mailto:haosd...@gmail.com] 
Sent: Wednesday, February 3, 2016 10:05 AM
To: dev 
Subject: Re: MESOS-4581 Docker containers getting stuck in staging.

Hi, Hegner. I think Joly means we change Docker::inspect from ```
  s.get().status()
.onAny([=]() { __inspect(cmd, promise, retryInterval, output, s.get()); }); 
``` to ```
  s.get().status()
.after(timeoutSeconds, []() {...})
.onAny([=]() { __inspect(cmd, promise, retryInterval, output, s.get()); }); 
```

Suppose if 500ms not works in different environments, we still would go into 
same problem. I think add timeout limit in inspect would be better.

On Wed, Feb 3, 2016 at 10:05 PM, Hegner, Travis 
wrote:

> Thanks Jojy,
>
> I agree that my current patch is not the most ideal solution, as it 
> was intended as a proof of concept to ensure that it was in fact the 
> timing that was causing the problems I've been experiencing. Perhaps I 
> didn't make that clear enough in the JIRA. That is also the reason I 
> haven't attempted to submit that patch back.
>
> I was hoping to open a dialog to discuss the most appropriate fix for 
> that error, as I am relatively new to the future/promise paradigm, and 
> I haven't done much in c++ in 10 years.
>
> I'm assuming that when you say "using 'after' on the future" you are 
> referring to the initial inspect call's future correct? In that case, 
> I'm not convinced that is the right solution either. If you dig into 
> the inspect call, you'll see that it has a fairly sophisticated retry 
> system itself. However, that retry system is designed around whether 
> the actual inspect command completes its execution. If the inspect 
> command runs forever, then that thread blocks waiting for it forever.
>
> I am leaning towards a combination of both. I believe that it is 
> appropriate to wait a small amount of time to call the initial 
> inspect, to give docker a chance to create and start the container. I 
> see your point in that there is still the possibility of a race 
> condition, if the run command is delayed for the right amount of time 
> itself, I understand that the run thread could be executed any time 
> after the future is created. When running the vanilla mesos (without 
> my current patch), remember that the containers that launch 
> successfully, actually do so because the initial inspect fails 
> (returns non 0 as the container doesn’t exist yet), and the inspect 
> function's built in retry system delays 500ms and runs again, this time 
> successfully. (See these logs to see what I mean:
> https://gist.github.com/travishegner/dcb5797f5a0919e45618)
>
> With that in mind, we wouldn't actually know whether the inspect is 
> just delayed in its own retry pattern, or is actually hung, unless we 
> wait a large enough amount of time. Given how frequently we encounter 
> this issue in our environment (more than half of the attempted 
> container launches), waiting a large amount of time to indicate 
> whether the container is running would be undesirable.
>
> How do you feel about an initial delay (how long 500ms?), in concert 
> with an ".after()" (how long 3000ms?) on the inspect future that will 
> discard the original inspect and try again? The initial delay would 
> give docker time to create and start our container, and in my 
> environment drastically reduce the frequency with which we are met 
> with this condition. Ironically, the variable name 
> (DOCKER_INSPECT_DELAY) of the retry delay, seems to indicate that the 
> author expected a delay to be inserted before the inspect call anyway, 
> but in reading through the code, that variable is only used as the retry 
> interval, and the initial docker inspect is executed immediately.
> A timeout/retry on the inspect call helps to guard against this type 
> of issue, should the run and inspect commands be launched 
> simultaneously for whatever reason.
>
> A final thought: are we looking at this from the wrong perspective? 
> Should the inspect call itself be modified to handle the case when the 
> inspect command never returns?
>
> Thanks for your thoughts,
>
> Travis
>
> -Original Message-
> From: Jojy Varghese [mailto:j...@mesosphere.io]
> Sent: Tuesday, February 2, 2016 10:34 PM
> To: dev@mesos.apache.org
> Subject: Re: MESOS-4581 Docker containers getting stuck in staging.
>
> Hi Travis
>  Thanks for narrowing down the issue. I had a brief look at your patch 
> and it looks 

Contributor request

[Evers Benno]

Hi,

can you please add me as a contributor in JIRA? My username is "bennoe".

Thanks,
Benno

Re: MESOS-4581 Docker containers getting stuck in staging.

[haosdent]

Hi, Hegner. I think Joly means we change Docker::inspect from
```
  s.get().status()
.onAny([=]() { __inspect(cmd, promise, retryInterval, output, s.get());
});
```
to
```
  s.get().status()
.after(timeoutSeconds, []() {...})
.onAny([=]() { __inspect(cmd, promise, retryInterval, output, s.get());
});
```

Suppose if 500ms not works in different environments, we still would go
into same problem. I think add timeout limit in inspect would be better.

On Wed, Feb 3, 2016 at 10:05 PM, Hegner, Travis 
wrote:

> Thanks Jojy,
>
> I agree that my current patch is not the most ideal solution, as it was
> intended as a proof of concept to ensure that it was in fact the timing
> that was causing the problems I've been experiencing. Perhaps I didn't make
> that clear enough in the JIRA. That is also the reason I haven't attempted
> to submit that patch back.
>
> I was hoping to open a dialog to discuss the most appropriate fix for that
> error, as I am relatively new to the future/promise paradigm, and I haven't
> done much in c++ in 10 years.
>
> I'm assuming that when you say "using 'after' on the future" you are
> referring to the initial inspect call's future correct? In that case, I'm
> not convinced that is the right solution either. If you dig into the
> inspect call, you'll see that it has a fairly sophisticated retry system
> itself. However, that retry system is designed around whether the actual
> inspect command completes its execution. If the inspect command runs
> forever, then that thread blocks waiting for it forever.
>
> I am leaning towards a combination of both. I believe that it is
> appropriate to wait a small amount of time to call the initial inspect, to
> give docker a chance to create and start the container. I see your point in
> that there is still the possibility of a race condition, if the run command
> is delayed for the right amount of time itself, I understand that the run
> thread could be executed any time after the future is created. When running
> the vanilla mesos (without my current patch), remember that the containers
> that launch successfully, actually do so because the initial inspect fails
> (returns non 0 as the container doesn’t exist yet), and the inspect
> function's built in retry system delays 500ms and runs again, this time
> successfully. (See these logs to see what I mean:
> https://gist.github.com/travishegner/dcb5797f5a0919e45618)
>
> With that in mind, we wouldn't actually know whether the inspect is just
> delayed in its own retry pattern, or is actually hung, unless we wait a
> large enough amount of time. Given how frequently we encounter this issue
> in our environment (more than half of the attempted container launches),
> waiting a large amount of time to indicate whether the container is running
> would be undesirable.
>
> How do you feel about an initial delay (how long 500ms?), in concert with
> an ".after()" (how long 3000ms?) on the inspect future that will discard
> the original inspect and try again? The initial delay would give docker
> time to create and start our container, and in my environment drastically
> reduce the frequency with which we are met with this condition. Ironically,
> the variable name (DOCKER_INSPECT_DELAY) of the retry delay, seems to
> indicate that the author expected a delay to be inserted before the inspect
> call anyway, but in reading through the code, that variable is only used as
> the retry interval, and the initial docker inspect is executed immediately.
> A timeout/retry on the inspect call helps to guard against this type of
> issue, should the run and inspect commands be launched simultaneously for
> whatever reason.
>
> A final thought: are we looking at this from the wrong perspective? Should
> the inspect call itself be modified to handle the case when the inspect
> command never returns?
>
> Thanks for your thoughts,
>
> Travis
>
> -Original Message-
> From: Jojy Varghese [mailto:j...@mesosphere.io]
> Sent: Tuesday, February 2, 2016 10:34 PM
> To: dev@mesos.apache.org
> Subject: Re: MESOS-4581 Docker containers getting stuck in staging.
>
> Hi Travis
>  Thanks for narrowing down the issue. I had a brief look at your patch and
> it looks like it relies on adding delay before inspect is called. Although
> that might work mostly, I am wondering if that is the right solution. It
> would be better if we can have a timeout (using ‘after’ on the future) and
> retry inspect after timeout. We will have to discard the inspect future
> thats in flight.
>
> -Jojy
>
>
> > On Feb 2, 2016, at 1:12 PM, Hegner, Travis 
> wrote:
> >
> > I'd like to initiate a discussion on the following issue:
> >
> > https://issues.apache.org/jira/browse/MESOS-4581
> >
> > I've included a lot of detail in the JIRA, and would rather not
> reiterate _all_ of it here on the list, but in short:
> >
> > We are experiencing an issue when launching docker containers from
> marathon on mesos, where the container actually starts on th

RE: Shephard Reqeust: patch for MESOS-4370

[Hegner, Travis]

At the risk of sounding like a complainer: I feel that there is a very high 
barrier to entry when trying to help with this project. Perhaps many users are 
spoiled by github (myself included) because it's easy to suggest and discuss 
changes. At the risk of sounding lazy: I did read the submit-a-patch page and 
submitted the pull request on github anyway, in the hopes that I could avoid 
"going through all that work" to submit a patch. I was not confused, just 
hopeful. :)

In the end, my desire to get the patch merged upstream was stronger than my 
desire to maintain a separate fork of mesos. That is why I am now subscribed to 
this list.

In my opinion, the barrier to entry being so high to contribute will hinder 
community growth. If we weren't intending to use mesos in a production 
environment, I would never have submitted any patches back at all. Having to 
create and maintain multiple different user accounts, on multiple different 
tools, with multiple different interfaces is kind of burdensome. Not to mention 
that I personally do not like an email heavy workflow (despite my emails being 
novels, I know). I would have to assume that project maintainers are spending a 
lot of unnecessary time working with so many different tools, and having such a 
complicated workflow.

I believe that the current system is great to attract developers, who want to 
program something. However, difficult for "users" (like me) of the project who 
may be just savvy enough to troubleshoot, diagnose, and repair issues that they 
actually encounter when using the project, rather than just choosing a JIRA at 
random to work on.

I completely understand wanting to keep out "riff-raff" (for lack of a better 
term), but I believe that the high barrier to entry could be keeping out good 
suggestions, and submissions as well.

Of course, the project maintainers are free to do as they choose, I just felt 
obligated to share my opinion on the matter. I don't believe more documentation 
will solve that issue, and disabling pull requests may deter even more 
potential community members from participating. That said, ignoring pull 
requests may do even more harm than not allowing them in the first place.

Sorry if I'm being a bit too forward here, but as an outsider really trying to 
help, this is what I see.

Thanks,

Travis


-Original Message-
From: haosdent [mailto:haosd...@gmail.com] 
Sent: Tuesday, February 2, 2016 8:27 PM
To: dev 
Subject: Re: Shephard Reqeust: patch for MESOS-4370

How about rename submitting-a-patch to CONTRIBUTING.md or create 
CONTRIBUTING.md which would show when user create pull request in github? 
Furthermore, because I saw we also submit doc through Review board, how about 
disable pull request in Github which let user confuse?

On Wed, Feb 3, 2016 at 4:41 AM, Hegner, Travis 
wrote:

> OK then, Thanks.
>
> Consider this message a formal request for contributor permissions so 
> that I can assign the JIRA to myelf.
>
> Travis
>
> -Original Message-
> From: Kapil Arya [mailto:ka...@mesosphere.io]
> Sent: Tuesday, February 2, 2016 3:04 PM
> To: dev 
> Subject: Re: Shephard Reqeust: patch for MESOS-4370
>
> Thanks for the explanation, Greg!!
>
> Travis,
>
> Thanks for contributing to Mesos. Please go through the contributor 
> guidelines as suggested by Greg. I can then shepherd the patch for you.
>
> Best,
> Kapil
>
>
> On Tue, Feb 2, 2016 at 2:56 PM, Greg Mann  wrote:
> > Hi Travis,
> > Thanks for your contribution! It's always great to see new 
> > contributors :-)
> >
> > A couple things regarding your patch:
> > Please have a look at the contribution guidelines here:
> > http://mesos.apache.org/documentation/latest/submitting-a-patch/
> >
> > The standard protocol when addressing a JIRA issue is to assign the 
> > issue to yourself on JIRA, and then find a "Shepherd" for the ticket 
> > before coding begins. The shepherd is a Mesos committer who will 
> > work with you to design the patch, and then commit it once it's complete.
> >
> > It also looks like the ticket you've been working on is currently in 
> > the "Open" state. This means that it hasn't been marked as "Accepted"
> > by an existing contributor, signifying that someone thinks it's an 
> > issue worth pursuing. In this case, the first step is to begin a 
> > discussion on the issue by commenting on JIRA, and perhaps drawing 
> > attention to it via this mailing list, to see how the community 
> > thinks
> we should proceed.
> >
> > I would recommend that you first assign MESOS-4370 to yourself (this 
> > will require contributor permissions on JIRA, which can be secured 
> > with a short email to this mailing list requesting them). You 
> > already did a good job of summarizing your approach in the 
> > description of your review request, which you also posted on JIRA, 
> > so hopefully this thread will draw the attention of some interested 
> > parties who can provide some feedback, as well as a committer who 
> > might h

RE: MESOS-4581 Docker containers getting stuck in staging.

[Hegner, Travis]

Thanks Jojy,

I agree that my current patch is not the most ideal solution, as it was 
intended as a proof of concept to ensure that it was in fact the timing that 
was causing the problems I've been experiencing. Perhaps I didn't make that 
clear enough in the JIRA. That is also the reason I haven't attempted to submit 
that patch back.

I was hoping to open a dialog to discuss the most appropriate fix for that 
error, as I am relatively new to the future/promise paradigm, and I haven't 
done much in c++ in 10 years.

I'm assuming that when you say "using 'after' on the future" you are referring 
to the initial inspect call's future correct? In that case, I'm not convinced 
that is the right solution either. If you dig into the inspect call, you'll see 
that it has a fairly sophisticated retry system itself. However, that retry 
system is designed around whether the actual inspect command completes its 
execution. If the inspect command runs forever, then that thread blocks waiting 
for it forever.

I am leaning towards a combination of both. I believe that it is appropriate to 
wait a small amount of time to call the initial inspect, to give docker a 
chance to create and start the container. I see your point in that there is 
still the possibility of a race condition, if the run command is delayed for 
the right amount of time itself, I understand that the run thread could be 
executed any time after the future is created. When running the vanilla mesos 
(without my current patch), remember that the containers that launch 
successfully, actually do so because the initial inspect fails (returns non 0 
as the container doesn’t exist yet), and the inspect function's built in retry 
system delays 500ms and runs again, this time successfully. (See these logs to 
see what I mean: https://gist.github.com/travishegner/dcb5797f5a0919e45618)

With that in mind, we wouldn't actually know whether the inspect is just 
delayed in its own retry pattern, or is actually hung, unless we wait a large 
enough amount of time. Given how frequently we encounter this issue in our 
environment (more than half of the attempted container launches), waiting a 
large amount of time to indicate whether the container is running would be 
undesirable.

How do you feel about an initial delay (how long 500ms?), in concert with an 
".after()" (how long 3000ms?) on the inspect future that will discard the 
original inspect and try again? The initial delay would give docker time to 
create and start our container, and in my environment drastically reduce the 
frequency with which we are met with this condition. Ironically, the variable 
name (DOCKER_INSPECT_DELAY) of the retry delay, seems to indicate that the 
author expected a delay to be inserted before the inspect call anyway, but in 
reading through the code, that variable is only used as the retry interval, and 
the initial docker inspect is executed immediately. A timeout/retry on the 
inspect call helps to guard against this type of issue, should the run and 
inspect commands be launched simultaneously for whatever reason.

A final thought: are we looking at this from the wrong perspective? Should the 
inspect call itself be modified to handle the case when the inspect command 
never returns?

Thanks for your thoughts,

Travis

-Original Message-
From: Jojy Varghese [mailto:j...@mesosphere.io] 
Sent: Tuesday, February 2, 2016 10:34 PM
To: dev@mesos.apache.org
Subject: Re: MESOS-4581 Docker containers getting stuck in staging.

Hi Travis
 Thanks for narrowing down the issue. I had a brief look at your patch and it 
looks like it relies on adding delay before inspect is called. Although that 
might work mostly, I am wondering if that is the right solution. It would be 
better if we can have a timeout (using ‘after’ on the future) and retry inspect 
after timeout. We will have to discard the inspect future thats in flight.

-Jojy


> On Feb 2, 2016, at 1:12 PM, Hegner, Travis  wrote:
> 
> I'd like to initiate a discussion on the following issue:
> 
> https://issues.apache.org/jira/browse/MESOS-4581
> 
> I've included a lot of detail in the JIRA, and would rather not reiterate 
> _all_ of it here on the list, but in short:
> 
> We are experiencing an issue when launching docker containers from marathon 
> on mesos, where the container actually starts on the slave node to which it's 
> assigned, but mesos/marathon get stuck in staging/staged respectively until 
> the task launch times out and system tries again to launch it elsewhere. This 
> issue is random in nature, successfully starting tasks about 40-50% of the 
> time, while the rest of the time getting stuck.
> 
> We've been able to narrow this down to a possible race condition likely in 
> docker itself, but being triggered by the mesos-docker-executor. I have 
> written and tested a patch in our environment which seems to have eliminated 
> the issue, however I feel that the patch could be made more robust, and is 
> cu

Re: Need a shepherd for https://issues.apache.org/jira/browse/MESOS-4446

[Abhishek Dasgupta]

Hi,

I have submitted the patch again modifying as per the review comment.
The link is https://reviews.apache.org/r/43032/
Please, have a look on it.

Jie, tim

Can you please shepherd this issue or redirect me to someone else whom I 
can ask for shepherding?


Thanks,
Abhishek Dasgupta

On Sunday 31 January 2016 09:02 PM, Abhishek Dasgupta wrote:

Hi,
Can anyone please shepherd the issue MESOS-4446?

Following is the link for patch : https://reviews.apache.org/r/43032/

Thank you.

On Saturday 30 January 2016 04:55 AM, Benjamin Mahler wrote:

+tim, jie since this is docker related

On Sun, Jan 24, 2016 at 10:31 AM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:


Hi,

Is there someone who can please shepherd the issue
https://issues.apache.org/jira/browse/MESOS-4446?
  We can have a discussion on designing this on the comment section. 
Thank

you.

--
   Regards,


--- 


   Abhishek Dasgupta
   Linux Software Developer - Linux Technology Centre
   IBM Systems Lab,
   IBM India Pvt. Ltd.
   Embassy Golf Link, D Block
   Koramongala - Off Indiranagar Ring Road
   Bangalore - 560 071
   Mobile: +91-8884107981

--- 








--
  Regards,

  
---
  Abhishek Dasgupta
  Linux Software Developer - Linux Technology Centre
  IBM Systems Lab,
  IBM India Pvt. Ltd.
  Embassy Golf Link, D Block
  Koramongala - Off Indiranagar Ring Road
  Bangalore - 560 071
  Mobile: +91-8884107981
  
---

Re: Version numbers in docs

[Alex Rukletsov]

But before we switch to version specific docs, I would like to keep the
version when a certain feature was introduced. This information should not
necessarily open the doc, but should be present somewhere, perhaps as a
side note.

On Wed, Feb 3, 2016 at 11:04 AM, Alexander Rojas 
wrote:

> I actually like the idea to have version specific documentation, since it
> is kind of the standard way of going about things.
>
> +1 to that.
>
>
> > On 03 Feb 2016, at 01:53, Neil Conway  wrote:
> >
> > I agree we should remove this text after some period of time has
> > passed since that version of Mesos was released; it is quite
> > distracting.
> >
> > The proper long-term fix is probably to have version-specific docs. So
> > all the documentation at
> >
> > /documentation/v0.27/...
> >
> > would implicitly discuss the features that are present in Mesos 0.27.
> > That would eliminate a lot of the need for version number references
> > in the documentation text itself.
> >
> > Neil
> >
> > On Tue, Feb 2, 2016 at 4:48 PM, Greg Mann  wrote:
> >> Hi all!
> >> In our docs, you find such sentences as:
> >>
> >> "Mesos 0.15.0 added support for framework authentication, and 0.19.0
> added
> >> slave authentication."
> >>
> >> It's a minor point, but I wonder how long we should maintain such
> version
> >> numbers in the docs? In the example above, my feeling is that we are far
> >> enough past 0.19.0 that we could change this to read simply, "Mesos
> >> supports authentication of both frameworks and slaves".
> >>
> >> Thoughts?
> >>
> >> Cheers,
> >> Greg
>
>

Re: Version numbers in docs

[Alexander Rojas]

I actually like the idea to have version specific documentation, since it is 
kind of the standard way of going about things.

+1 to that.


> On 03 Feb 2016, at 01:53, Neil Conway  wrote:
> 
> I agree we should remove this text after some period of time has
> passed since that version of Mesos was released; it is quite
> distracting.
> 
> The proper long-term fix is probably to have version-specific docs. So
> all the documentation at
> 
> /documentation/v0.27/...
> 
> would implicitly discuss the features that are present in Mesos 0.27.
> That would eliminate a lot of the need for version number references
> in the documentation text itself.
> 
> Neil
> 
> On Tue, Feb 2, 2016 at 4:48 PM, Greg Mann  wrote:
>> Hi all!
>> In our docs, you find such sentences as:
>> 
>> "Mesos 0.15.0 added support for framework authentication, and 0.19.0 added
>> slave authentication."
>> 
>> It's a minor point, but I wonder how long we should maintain such version
>> numbers in the docs? In the example above, my feeling is that we are far
>> enough past 0.19.0 that we could change this to read simply, "Mesos
>> supports authentication of both frameworks and slaves".
>> 
>> Thoughts?
>> 
>> Cheers,
>> Greg

Review request[#43136 ]

[pangbingqiang]

Hi, All:
  I submit a patch, please take a time to review, if have any problem please 
let me know, Thanks!
  https://reviews.apache.org/r/43136/diff/1#index_header


[cid:image001.png@01D0E8C5.8D08F440]


Bingqiang Pang 00278970


Distributed Software Lab
Huawei Technologies Co., Ltd.
Email:pangbingqi...@huawei.com