[jira] [Assigned] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-4611:
---
Assignee: haosdent
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
>Assignee: haosdent
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223615#comment-15223615
]
haosdent commented on MESOS-4611:
-
Thanks [~mcypark] and [~klueska]'s nice explanations. Let me try to follow your
comments.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223603#comment-15223603
]
Michael Park commented on MESOS-4611:
-
I'm happy to shepherd this if someone would like to write a patch.
The issue is not that lambdas are not implicitly convertible to a
{{std::function}}. They absolutely are.
However, for a function parameter with a template parameter which is deduced,
the argument must be of exact type.
Recall that the type of a lambda is an anonymous type generated by the
compiler, not {{std::function}}.
With that in mind, consider this small example:
{code}
template struct S{ S(int); };
template void F(S);
{code}
Although {{int}} is implicitly convertible to {{S}} for any {{T}},
Given {{F(42)}}, the compiler has no idea what to deduce {{U}} to be.
We can however, do:
{code}
S x = 42; // The `double` is irrelevant.
F(x); // `T` can be deduced to be `double`.
{code}
If you were to replace {{S}} with {{std::function}}, {{42}} with the lambda,
{{F}} with {{dispatch}},
you'll see that everything is consistent.
Now, for the fix we need to use a similar technique as the one we use in
{{future.hpp}}.
That is, rather than using {{std::function}}, we simply use a template
parameter {{F}} and use
{{result_of}} to constrain it correctly.
For example,
{code}
template
Future dispatch(const UPID& pid, const std::function& f);
{code}
should be something like:
{code}
template
Future::type> dispatch(const UPID& pid, F&& f);
{code}
It's not that straight-forward since there are 3 overloads, but as I said, I
can help out with this.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223600#comment-15223600
]
Yong Tang commented on MESOS-4112:
--
Hi [~mcypark], the review requests have been updated. They are now located in:
https://reviews.apache.org/r/45357/
https://reviews.apache.org/r/45664/
https://reviews.apache.org/r/45663/
Please let me know if there are any issues.
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> ~~(4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.~~
> (5) There are a few more missing macros, given {{AWAIT_EQ_FOR}} and
> {{AWAIT_EQ}} which aliases to {{AWAIT_ASSERT_EQ_FOR}} and {{AWAIT_ASSERT_EQ}}
> respectively, we should also add {{AWAIT_TRUE_FOR}}, {{AWAIT_TRUE}},
> {{AWAIT_FALSE_FOR}}, and {{AWAIT_FALSE}} as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park updated MESOS-4611:
Shepherd: Michael Park
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136387#comment-15136387
]
Michael Park edited comment on MESOS-4611 at 4/4/16 1:42 AM:
-
No, that has the same problem. [~mcypark] summarized for me offline why our
current templates can't match this. The basic problem is that lambda's cant be
implicitly cast to the std::function() type, so we end up matching with a
different dispatch() template which returns a void.
was (Author: klueska):
No, that has the same problem. [~mpark] summarized for me offline why our
current templates can't match this. The basic problem is that lambda's cant be
implicitly cast to the std::function() type, so we end up matching with a
different dispatch() template which returns a void.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park updated MESOS-4112:
Description:
This ticket is regarding the libprocess gtest helpers in
{{3rdparty/libprocess/include/process/gtest.hpp}}.
The pattern in this file seems to be a set of macros:
* {{AWAIT_ASSERT__FOR}}
* {{AWAIT_ASSERT_}} -- default of 15 seconds
* {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
* {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
* {{AWAIT_EXPECT__FOR}}
* {{AWAIT_EXPECT_}} -- default of 15 seconds
(1) {{AWAIT_EQ_FOR}} should be added for completeness.
(2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
We should adopt this pattern in these helpers as well. Keeping the pattern
above in mind, the following are missing:
* {{AWAIT_ASSERT_TRUE_FOR}}
* {{AWAIT_ASSERT_TRUE}}
* {{AWAIT_ASSERT_FALSE_FOR}}
* {{AWAIT_ASSERT_FALSE}}
* {{AWAIT_EXPECT_TRUE_FOR}}
* {{AWAIT_EXPECT_FALSE_FOR}}
(3) There are HTTP response related macros at the bottom of the file, e.g.
{{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their {{ASSERT}}
counterparts.
~~(4) The reason for (3) presumably is because we reach for {{EXPECT}} over
{{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}. If
this is the case, it would be worthwhile considering whether macros such as
{{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
{{AWAIT_ASSERT_READY}}.~~
(5) There are a few more missing macros, given {{AWAIT_EQ_FOR}} and
{{AWAIT_EQ}} which aliases to {{AWAIT_ASSERT_EQ_FOR}} and {{AWAIT_ASSERT_EQ}}
respectively, we should also add {{AWAIT_TRUE_FOR}}, {{AWAIT_TRUE}},
{{AWAIT_FALSE_FOR}}, and {{AWAIT_FALSE}} as well.
was:
This ticket is regarding the libprocess gtest helpers in
{{3rdparty/libprocess/include/process/gtest.hpp}}.
The pattern in this file seems to be a set of macros:
* {{AWAIT_ASSERT__FOR}}
* {{AWAIT_ASSERT_}} -- default of 15 seconds
* {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
* {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
* {{AWAIT_EXPECT__FOR}}
* {{AWAIT_EXPECT_}} -- default of 15 seconds
(1) {{AWAIT_EQ_FOR}} should be added for completeness.
(2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
We should adopt this pattern in these helpers as well. Keeping the pattern
above in mind, the following are missing:
* {{AWAIT_ASSERT_TRUE_FOR}}
* {{AWAIT_ASSERT_TRUE}}
* {{AWAIT_ASSERT_FALSE_FOR}}
* {{AWAIT_ASSERT_FALSE}}
* {{AWAIT_EXPECT_TRUE_FOR}}
* {{AWAIT_EXPECT_FALSE_FOR}}
(3) There are HTTP response related macros at the bottom of the file, e.g.
{{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their {{ASSERT}}
counterparts.
(4) The reason for (3) presumably is because we reach for {{EXPECT}} over
{{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}. If
this is the case, it would be worthwhile considering whether macros such as
{{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
{{AWAIT_ASSERT_READY}}.
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> ~~(4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.~~
> (5) There are a few more
[jira] [Updated] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park updated MESOS-4112:
Sprint: Mesosphere Sprint 32
Story Points: 2
> Clean up libprocess gtest macros
>
>
> Key: MESOS-4112
> URL: https://issues.apache.org/jira/browse/MESOS-4112
> Project: Mesos
> Issue Type: Task
> Components: libprocess, test
>Reporter: Michael Park
>Assignee: Yong Tang
>
> This ticket is regarding the libprocess gtest helpers in
> {{3rdparty/libprocess/include/process/gtest.hpp}}.
> The pattern in this file seems to be a set of macros:
> * {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_ASSERT_}} -- default of 15 seconds
> * {{AWAIT_\_FOR}} -- alias for {{AWAIT_ASSERT__FOR}}
> * {{AWAIT_}} -- alias for {{AWAIT_ASSERT_}}
> * {{AWAIT_EXPECT__FOR}}
> * {{AWAIT_EXPECT_}} -- default of 15 seconds
> (1) {{AWAIT_EQ_FOR}} should be added for completeness.
> (2) In {{gtest}}, we've got {{EXPECT_EQ}} as well as the {{bool}}-specific
> versions: {{EXPECT_TRUE}} and {{EXPECT_FALSE}}.
> We should adopt this pattern in these helpers as well. Keeping the pattern
> above in mind, the following are missing:
> * {{AWAIT_ASSERT_TRUE_FOR}}
> * {{AWAIT_ASSERT_TRUE}}
> * {{AWAIT_ASSERT_FALSE_FOR}}
> * {{AWAIT_ASSERT_FALSE}}
> * {{AWAIT_EXPECT_TRUE_FOR}}
> * {{AWAIT_EXPECT_FALSE_FOR}}
> (3) There are HTTP response related macros at the bottom of the file, e.g.
> {{AWAIT_EXPECT_RESPONSE_STATUS_EQ}}, however these are missing their
> {{ASSERT}} counterparts.
> (4) The reason for (3) presumably is because we reach for {{EXPECT}} over
> {{ASSERT}} in general due to the test suite crashing behavior of {{ASSERT}}.
> If this is the case, it would be worthwhile considering whether macros such
> as {{AWAIT_READY}} should alias {{AWAIT_EXPECT_READY}} rather than
> {{AWAIT_ASSERT_READY}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5101) Add CMake build to docker_build.sh
Juan Larriba created MESOS-5101: --- Summary: Add CMake build to docker_build.sh Key: MESOS-5101 URL: https://issues.apache.org/jira/browse/MESOS-5101 Project: Mesos Issue Type: Improvement Reporter: Juan Larriba Add the CMake build system to docker_build.sh to automatically test the build on Jenkins alongside gcc and clang. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3435) Add Hyper as Mesos Docker alike support
[ https://issues.apache.org/jira/browse/MESOS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3435: Issue Type: Story (was: Improvement) > Add Hyper as Mesos Docker alike support > --- > > Key: MESOS-3435 > URL: https://issues.apache.org/jira/browse/MESOS-3435 > Project: Mesos > Issue Type: Story >Reporter: Deshi Xiao >Assignee: haosdent > > Hyper is Hypervisor-agnostic Docker Engine, I hope marathon can support > it.(https://github.com/mesosphere/marathon/issues/1815) > https://hyper.sh/ > In earlier talk about the implement possible with with Tim Chen, He suggest > firstly implement the engine like mesos-src/docker/docker.hpp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2162) Consider a C++ implementation of CoreOS AppContainer spec
[ https://issues.apache.org/jira/browse/MESOS-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223384#comment-15223384 ] haosdent commented on MESOS-2162: - I would like to add the rkt as an example of containerizer modularization as well once MESOS-3709 is done. > Consider a C++ implementation of CoreOS AppContainer spec > - > > Key: MESOS-2162 > URL: https://issues.apache.org/jira/browse/MESOS-2162 > Project: Mesos > Issue Type: Story > Components: containerization >Reporter: Dominic Hamon > Labels: gsoc2015, mesosphere, twitter > > CoreOS have released a > [specification|https://github.com/coreos/rocket/blob/master/app-container/SPEC.md] > for a container abstraction as an alternative to Docker. They have also > released a reference implementation, [rocket|https://coreos.com/blog/rocket/]. > We should consider a C++ implementation of the specification to have parity > with the community and then use this implementation for our containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3435) Add Hyper as Mesos Docker alike support
[ https://issues.apache.org/jira/browse/MESOS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3435: --- Assignee: haosdent > Add Hyper as Mesos Docker alike support > --- > > Key: MESOS-3435 > URL: https://issues.apache.org/jira/browse/MESOS-3435 > Project: Mesos > Issue Type: Improvement >Reporter: Deshi Xiao >Assignee: haosdent > > Hyper is Hypervisor-agnostic Docker Engine, I hope marathon can support > it.(https://github.com/mesosphere/marathon/issues/1815) > https://hyper.sh/ > In earlier talk about the implement possible with with Tim Chen, He suggest > firstly implement the engine like mesos-src/docker/docker.hpp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2162) Consider a C++ implementation of CoreOS AppContainer spec
[ https://issues.apache.org/jira/browse/MESOS-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-2162: --- Assignee: haosdent > Consider a C++ implementation of CoreOS AppContainer spec > - > > Key: MESOS-2162 > URL: https://issues.apache.org/jira/browse/MESOS-2162 > Project: Mesos > Issue Type: Story > Components: containerization >Reporter: Dominic Hamon >Assignee: haosdent > Labels: gsoc2015, mesosphere, twitter > > CoreOS have released a > [specification|https://github.com/coreos/rocket/blob/master/app-container/SPEC.md] > for a container abstraction as an alternative to Docker. They have also > released a reference implementation, [rocket|https://coreos.com/blog/rocket/]. > We should consider a C++ implementation of the specification to have parity > with the community and then use this implementation for our containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3435) Add Hyper as Mesos Docker alike support
[ https://issues.apache.org/jira/browse/MESOS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223381#comment-15223381 ] haosdent commented on MESOS-3435: - I would like to add the hyper as an example of containerizer modularization once [MESOS-3709|https://issues.apache.org/jira/browse/MESOS-3709] is done. > Add Hyper as Mesos Docker alike support > --- > > Key: MESOS-3435 > URL: https://issues.apache.org/jira/browse/MESOS-3435 > Project: Mesos > Issue Type: Improvement >Reporter: Deshi Xiao > > Hyper is Hypervisor-agnostic Docker Engine, I hope marathon can support > it.(https://github.com/mesosphere/marathon/issues/1815) > https://hyper.sh/ > In earlier talk about the implement possible with with Tim Chen, He suggest > firstly implement the engine like mesos-src/docker/docker.hpp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223379#comment-15223379 ] haosdent commented on MESOS-3709: - [~tillt] I have already public the patches I mentioned in the design document, do have have cycles to review recently? Thank you in advance. > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5100) Add CustomInfo for custom container to ContainerInfo protobuf
haosdent created MESOS-5100: --- Summary: Add CustomInfo for custom container to ContainerInfo protobuf Key: MESOS-5100 URL: https://issues.apache.org/jira/browse/MESOS-5100 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223363#comment-15223363 ] haosdent commented on MESOS-3709: - Hi, [~xds2000] I refactor my patches before and public the new design document. I think you could take a look of them. > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Comment: was deleted (was: Patch: https://reviews.apache.org/r/41590/) > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Description: So that people can implement their own containerizer as a module. That's more efficient than having an external containerizer and shell out. The module system also provides versioning support, this is definitely better than unversioned external containerizer. Design Doc: https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing was:So that people can implement their own containerizer as a module. That's more efficient than having an external containerizer and shell out. The module system also provides versioning support, this is definitely better than unversioned external containerizer. > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Comment: was deleted (was: The draft patch: https://reviews.apache.org/r/41590/ So far I still have two tasks to do: * rename the namespace and make it publicable. * fix the test case compile error.) > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Summary: Modularize the containerizer interface. (was: Modulize the containerizer interface.) > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5090) Move executorEnvironment out of containerizer interface
[ https://issues.apache.org/jira/browse/MESOS-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223314#comment-15223314 ] haosdent edited comment on MESOS-5090 at 4/3/16 2:04 PM: - Patch: | Move `executorEnvironment` out of containerizer interface. | https://reviews.apache.org/r/45648 | | Update header files for `executorEnvironment`. | https://reviews.apache.org/r/45649 | was (Author: haosd...@gmail.com): Patch: | Move `executorEnvironment` out of containerizer interface. | https://reviews.apache.org/r/45648 | > Move executorEnvironment out of containerizer interface > --- > > Key: MESOS-5090 > URL: https://issues.apache.org/jira/browse/MESOS-5090 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5099) Use Parameters as ComposingContainerizer::create parameters type
haosdent created MESOS-5099: --- Summary: Use Parameters as ComposingContainerizer::create parameters type Key: MESOS-5099 URL: https://issues.apache.org/jira/browse/MESOS-5099 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5098) Use Parameters as ExternalContainerizer::create parameters type
haosdent created MESOS-5098: --- Summary: Use Parameters as ExternalContainerizer::create parameters type Key: MESOS-5098 URL: https://issues.apache.org/jira/browse/MESOS-5098 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5097) Use Parameters as DockerContainerizer::create parameters type
haosdent created MESOS-5097: --- Summary: Use Parameters as DockerContainerizer::create parameters type Key: MESOS-5097 URL: https://issues.apache.org/jira/browse/MESOS-5097 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5096) Use Parameters as MesosContainerizer::create parameters type
haosdent created MESOS-5096: --- Summary: Use Parameters as MesosContainerizer::create parameters type Key: MESOS-5096 URL: https://issues.apache.org/jira/browse/MESOS-5096 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5095) Remove Fetcher in DockerContainerizer::create interface
haosdent created MESOS-5095: --- Summary: Remove Fetcher in DockerContainerizer::create interface Key: MESOS-5095 URL: https://issues.apache.org/jira/browse/MESOS-5095 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5094) Remove Fetcher in MesosContainerizer::create interface
haosdent created MESOS-5094: --- Summary: Remove Fetcher in MesosContainerizer::create interface Key: MESOS-5094 URL: https://issues.apache.org/jira/browse/MESOS-5094 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5085) Remove SlaveState in Containerizer::recover interface
[ https://issues.apache.org/jira/browse/MESOS-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223291#comment-15223291 ] haosdent commented on MESOS-5085: - Patch: | Update `Slave::_recoverContainerizer` to use `ContainerState`. | https://reviews.apache.org/r/44798 | | Remove `SlaveState` in `MesosContainerizer` during recover. | https://reviews.apache.org/r/44822 | | Remove `SlaveState` in `DockerContainerizer` during recover. | https://reviews.apache.org/r/44823 | | Remove `SlaveState` in `ComposingContainerizer` during recover. | https://reviews.apache.org/r/44824 | | Remove `SlaveState` in `ExternalContainerizer` during recover. | https://reviews.apache.org/r/44825 | | Remove `SlaveState` in `TestContainerizer` during recover. | https://reviews.apache.org/r/44826 | | Remove `SlaveState` in ContainerLoggerTest related test cases. | https://reviews.apache.org/r/44828 | > Remove SlaveState in Containerizer::recover interface > - > > Key: MESOS-5085 > URL: https://issues.apache.org/jira/browse/MESOS-5085 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5085) Remove SlaveState in Containerizer::recover interface
[ https://issues.apache.org/jira/browse/MESOS-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-5085: Description: (was: Patch: | Update `Slave::_recoverContainerizer` to use `ContainerState`. | https://reviews.apache.org/r/44798 | | Remove `SlaveState` in `MesosContainerizer` during recover. | https://reviews.apache.org/r/44822 | | Remove `SlaveState` in `DockerContainerizer` during recover. | https://reviews.apache.org/r/44823 | | Remove `SlaveState` in `ComposingContainerizer` during recover. | https://reviews.apache.org/r/44824 | | Remove `SlaveState` in `ExternalContainerizer` during recover. | https://reviews.apache.org/r/44825 | | Remove `SlaveState` in `TestContainerizer` during recover. | https://reviews.apache.org/r/44826 | | Remove `SlaveState` in ContainerLoggerTest related test cases. | https://reviews.apache.org/r/44828 |) > Remove SlaveState in Containerizer::recover interface > - > > Key: MESOS-5085 > URL: https://issues.apache.org/jira/browse/MESOS-5085 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5093) Add containerizer module header
haosdent created MESOS-5093: --- Summary: Add containerizer module header Key: MESOS-5093 URL: https://issues.apache.org/jira/browse/MESOS-5093 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5092) Public Containerizer interface file
haosdent created MESOS-5092: --- Summary: Public Containerizer interface file Key: MESOS-5092 URL: https://issues.apache.org/jira/browse/MESOS-5092 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5090) Move executorEnvironment out of containerizer interface
haosdent created MESOS-5090: --- Summary: Move executorEnvironment out of containerizer interface Key: MESOS-5090 URL: https://issues.apache.org/jira/browse/MESOS-5090 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5091) Move Containerizer::resources out of containerizer interface
haosdent created MESOS-5091: --- Summary: Move Containerizer::resources out of containerizer interface Key: MESOS-5091 URL: https://issues.apache.org/jira/browse/MESOS-5091 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5089) Remove PID in containerizer interfaces
haosdent created MESOS-5089: --- Summary: Remove PID in containerizer interfaces Key: MESOS-5089 URL: https://issues.apache.org/jira/browse/MESOS-5089 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5088) Use Parameters as Containerizer::create parameters type
haosdent created MESOS-5088: --- Summary: Use Parameters as Containerizer::create parameters type Key: MESOS-5088 URL: https://issues.apache.org/jira/browse/MESOS-5088 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5087) Add jsonify for FlagsBase
haosdent created MESOS-5087: --- Summary: Add jsonify for FlagsBase Key: MESOS-5087 URL: https://issues.apache.org/jira/browse/MESOS-5087 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5086) Remove Fetcher in Containerizer::create interface
haosdent created MESOS-5086: --- Summary: Remove Fetcher in Containerizer::create interface Key: MESOS-5086 URL: https://issues.apache.org/jira/browse/MESOS-5086 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3709) Modulize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Epic Name: containerizer modularization > Modulize the containerizer interface. > - > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3709) Modulize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Labels: containerizer modularization module (was: ) > Modulize the containerizer interface. > - > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3709) Modulize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3709: Component/s: modules containerization > Modulize the containerizer interface. > - > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5085) Remove SlaveState in Containerizer::recover interface
haosdent created MESOS-5085: --- Summary: Remove SlaveState in Containerizer::recover interface Key: MESOS-5085 URL: https://issues.apache.org/jira/browse/MESOS-5085 Project: Mesos Issue Type: Task Components: containerization, modules Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5084) Add agent flag to config dvdcli for mount and unmount
Guangya Liu created MESOS-5084: -- Summary: Add agent flag to config dvdcli for mount and unmount Key: MESOS-5084 URL: https://issues.apache.org/jira/browse/MESOS-5084 Project: Mesos Issue Type: Bug Reporter: Guangya Liu Assignee: Guangya Liu Add an agent flag to enable mesos agent can find the dvdcli binary the mount point management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5083) Implement Docker Volume Isolator
Guangya Liu created MESOS-5083: -- Summary: Implement Docker Volume Isolator Key: MESOS-5083 URL: https://issues.apache.org/jira/browse/MESOS-5083 Project: Mesos Issue Type: Bug Reporter: Guangya Liu Assignee: Guangya Liu Add a new isolator for external storage integration based on docker volume API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
