[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15810591#comment-15810591 ] Yong Tang commented on MESOS-5227: -- [~anandmazumdar] I haven't had much time to work on this issue recently. Will try to see if I could spend some time after I am back from traveling. In the meantime, don't wait for me if any one is interested in taking over. > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433858#comment-15433858 ] Yong Tang commented on MESOS-5227: -- The review request has been updated again. Now the new RR are located: https://reviews.apache.org/r/51351/ https://reviews.apache.org/r/51352/ Please discard the old ones. > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4070) numify() handles negative numbers inconsistently.
[
https://issues.apache.org/jira/browse/MESOS-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15394706#comment-15394706
]
Yong Tang commented on MESOS-4070:
--
A new RR has been posted:
https://reviews.apache.org/r/50473/
The new RR above replaces the old RR (45011).
> numify() handles negative numbers inconsistently.
> -
>
> Key: MESOS-4070
> URL: https://issues.apache.org/jira/browse/MESOS-4070
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Jie Yu
>Assignee: Yong Tang
> Labels: tech-debt
> Fix For: 1.1.0
>
>
> As pointed by [~neilc] in this review:
> https://reviews.apache.org/r/40988
> {noformat}
> Try num2 = numify("-10");
> EXPECT_SOME_EQ(-10, num2);
> // TODO(neilc): This is inconsistent with the handling of non-hex numbers.
> EXPECT_ERROR(numify("-0x10"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5186) mesos.interface: Allow using protobuf 3.x
[
https://issues.apache.org/jira/browse/MESOS-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15380866#comment-15380866
]
Yong Tang commented on MESOS-5186:
--
[~xds2000] protobuf 3.0 is still in beta but it looks like protobuf 3 will be
released around end of July:
https://groups.google.com/forum/#!topic/protobuf/NcK5ae8ZUSU
I think we could wait until 3.0 is released.
> mesos.interface: Allow using protobuf 3.x
> -
>
> Key: MESOS-5186
> URL: https://issues.apache.org/jira/browse/MESOS-5186
> Project: Mesos
> Issue Type: Improvement
> Components: python api
>Reporter: Myautsai PAN
>Assignee: Yong Tang
>Priority: Minor
> Labels: easyfix
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> We're working on integrating TensorFlow(https://www.tensorflow.org) with
> mesos. Both the two require {{protobuf}}. The python package
> {{mesos.interface}} requires {{protobuf>=2.6.1,<3}}, but {{tensorflow}}
> requires {{protobuf>=3.0.0}} . Though protobuf 3.x is not compatible with
> protobuf 2.x, but anyway we modify the {{setup.py}}
> (https://github.com/apache/mesos/blob/66cddaf/src/python/interface/setup.py.in#L29)
> from {{'install_requires': [ 'google-common>=0.0.1', 'protobuf>=2.6.1,<3'
> ],}} to {{'install_requires': [ 'google-common>=0.0.1', 'protobuf>=2.6.1' ],}}
> It works fine. Would you please consider support protobuf 3.x officially in
> the next release? Maybe just remove the {{,<3}} restriction is enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352279#comment-15352279 ] Yong Tang commented on MESOS-5227: -- [~guoger] The review request has been updated. Now there is only one RR related to this issue: https://reviews.apache.org/r/49240/ > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15254131#comment-15254131 ] Yong Tang commented on MESOS-5227: -- Thanks [~alexr]! That will be much appreciated. I will add to the reviewer list when I submit the review request. Thanks. > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15254040#comment-15254040 ] Yong Tang commented on MESOS-5227: -- Hi [~alexr] I just started a couple of days ago. Still looking into how MESOS-3558 handles HTTP executor at the moment. > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-5227: Assignee: Yong Tang > Implement HTTP Docker Executor that uses the Executor Library > - > > Key: MESOS-5227 > URL: https://issues.apache.org/jira/browse/MESOS-5227 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Yong Tang > > Similar to what we did with the HTTP command executor in MESOS-3558 we should > have a HTTP docker executor that can speak the v1 Executor API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5031) Authorization Action enum does not support upgrades.
[ https://issues.apache.org/jira/browse/MESOS-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247097#comment-15247097 ] Yong Tang commented on MESOS-5031: -- Hi [~bmahler] I just created a pull request to address the "default" issue: https://reviews.apache.org/r/46364/ Please let me know if there are any issues. cc [~vinodkone] [~adam-mesos] > Authorization Action enum does not support upgrades. > > > Key: MESOS-5031 > URL: https://issues.apache.org/jira/browse/MESOS-5031 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.29.0 >Reporter: Adam B >Assignee: Yong Tang > Labels: mesosphere, security > Fix For: 0.29.0 > > > We need to make the Action enum optional in authorization::Request, and add > an `UNKNOWN = 0;` enum value. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5197) Log executor commands w/o verbose logs enabled
[ https://issues.apache.org/jira/browse/MESOS-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242312#comment-15242312 ] Yong Tang commented on MESOS-5197: -- Hi [~hartem] [~mgummelt] [~kaysoky] I created a pull request for this issue: https://reviews.apache.org/r/46246/ Please take a look and see if it meets the expectations. Thanks. > Log executor commands w/o verbose logs enabled > -- > > Key: MESOS-5197 > URL: https://issues.apache.org/jira/browse/MESOS-5197 > Project: Mesos > Issue Type: Task >Reporter: Michael Gummelt >Assignee: Yong Tang > Labels: mesosphere > > To debug executors, it's often necessary to know the command that ran the > executor. For example, when Spark executors fail, I'd like to know the > command used to invoke the executor (Spark uses the command executor in a > docker container). Currently, it's only output if GLOG_v is enabled, but I > don't think this should be a "verbose" output. It's a common debugging need. > https://github.com/apache/mesos/blob/2e76199a3dd977152110fbb474928873f31f7213/src/docker/docker.cpp#L677 > cc [~kaysoky] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5197) Log executor commands w/o verbose logs enabled
[ https://issues.apache.org/jira/browse/MESOS-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-5197: Assignee: Yong Tang > Log executor commands w/o verbose logs enabled > -- > > Key: MESOS-5197 > URL: https://issues.apache.org/jira/browse/MESOS-5197 > Project: Mesos > Issue Type: Task >Reporter: Michael Gummelt >Assignee: Yong Tang > Labels: mesosphere > > To debug executors, it's often necessary to know the command that ran the > executor. For example, when Spark executors fail, I'd like to know the > command used to invoke the executor (Spark uses the command executor in a > docker container). Currently, it's only output if GLOG_v is enabled, but I > don't think this should be a "verbose" output. It's a common debugging need. > https://github.com/apache/mesos/blob/2e76199a3dd977152110fbb474928873f31f7213/src/docker/docker.cpp#L677 > cc [~kaysoky] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5186) mesos.interface: Allow using protobuf 3.x
[
https://issues.apache.org/jira/browse/MESOS-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-5186:
Assignee: Yong Tang
> mesos.interface: Allow using protobuf 3.x
> -
>
> Key: MESOS-5186
> URL: https://issues.apache.org/jira/browse/MESOS-5186
> Project: Mesos
> Issue Type: Improvement
> Components: python api
>Reporter: Myautsai PAN
>Assignee: Yong Tang
>Priority: Minor
> Labels: easyfix
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> We're working on integrating TensorFlow(https://www.tensorflow.org) with
> mesos. Both the two require {{protobuf}}. The python package
> {{mesos.interface}} requires {{protobuf>=2.6.1,<3}}, but {{tensorflow}}
> requires {{protobuf>=3.0.0}} . Though protobuf 3.x is not compatible with
> protobuf 2.x, but anyway we modify the {{setup.py}}
> (https://github.com/apache/mesos/blob/66cddaf/src/python/interface/setup.py.in#L29)
> from {{'install_requires': [ 'google-common>=0.0.1', 'protobuf>=2.6.1,<3'
> ],}} to {{'install_requires': [ 'google-common>=0.0.1', 'protobuf>=2.6.1' ],}}
> It works fine. Would you please consider support protobuf 3.x officially in
> the next release? Maybe just remove the {{,<3}} restriction is enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4070) numify() handles negative numbers inconsistently.
[
https://issues.apache.org/jira/browse/MESOS-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235077#comment-15235077
]
Yong Tang commented on MESOS-4070:
--
Hi [~jieyu], I am wondering if you get a chance to take a look at the review
request:
https://reviews.apache.org/r/45011/
And since you initially opened this JIRA ticket (MESOS-4070), is it possible
for you to shepherd this ticket? Thanks.
> numify() handles negative numbers inconsistently.
> -
>
> Key: MESOS-4070
> URL: https://issues.apache.org/jira/browse/MESOS-4070
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Jie Yu
>Assignee: Yong Tang
> Labels: tech-debt
>
> As pointed by [~neilc] in this review:
> https://reviews.apache.org/r/40988
> {noformat}
> Try num2 = numify("-10");
> EXPECT_SOME_EQ(-10, num2);
> // TODO(neilc): This is inconsistent with the handling of non-hex numbers.
> EXPECT_ERROR(numify("-0x10"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235072#comment-15235072
]
Yong Tang commented on MESOS-4621:
--
Hi [~tillt], just wondering if you get a chance to take a look at the review
request for:
https://reviews.apache.org/r/44911/
Or do you think we should close this issue MESOS-4621 and continue on the other
issue MESOS-2537 by [~jamespeach]?
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
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] [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=15219959#comment-15219959
]
Yong Tang commented on MESOS-4112:
--
Hi, [~mcypark], any update to the review request:
https://reviews.apache.org/r/45356/
https://reviews.apache.org/r/45357/
Comments or feedback would be highly appreciated.
> 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] [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=15213234#comment-15213234
]
Yong Tang commented on MESOS-4112:
--
[~mcypark], thanks for the review.
I updated the usage of macros to replace EQ(true and EQ(false with
..._TRUE/_FALSE. The review request is below:
https://reviews.apache.org/r/45356/
I also added the HTTP response related macros (counterpart of existing macros)
with the review request:
https://reviews.apache.org/r/45357/
Please let me know if there are any issues. Again, thanks for the review!
> 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] [Updated] (MESOS-4601) Don't dump stack trace on failure to bind()
[
https://issues.apache.org/jira/browse/MESOS-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang updated MESOS-4601:
-
Assignee: (was: Yong Tang)
> Don't dump stack trace on failure to bind()
> ---
>
> Key: MESOS-4601
> URL: https://issues.apache.org/jira/browse/MESOS-4601
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
> Labels: errorhandling, libprocess, mesosphere, newbie
>
> We should do {{EXIT(EXIT_FAILURE)}} rather than {{LOG(FATAL)}}, both for this
> code path and a few other expected error conditions in libprocess network
> initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5031) Authorization Action enum does not support upgrades.
[ https://issues.apache.org/jira/browse/MESOS-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15212336#comment-15212336 ] Yong Tang commented on MESOS-5031: -- Hi [~adam-mesos] I just added a review request: https://reviews.apache.org/r/45342/ Let me know if there are any issues. > Authorization Action enum does not support upgrades. > > > Key: MESOS-5031 > URL: https://issues.apache.org/jira/browse/MESOS-5031 > Project: Mesos > Issue Type: Bug >Reporter: Adam B >Assignee: Yong Tang > Labels: mesosphere, security > Fix For: 0.29.0 > > > We need to make the Action enum optional in authorization::Request, and add > an `UNKNOWN = 0;` enum value. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5031) Authorization Action enum does not support upgrades.
[ https://issues.apache.org/jira/browse/MESOS-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-5031: Assignee: Yong Tang > Authorization Action enum does not support upgrades. > > > Key: MESOS-5031 > URL: https://issues.apache.org/jira/browse/MESOS-5031 > Project: Mesos > Issue Type: Bug >Reporter: Adam B >Assignee: Yong Tang > Labels: mesosphere, security > Fix For: 0.29.0 > > > We need to make the Action enum optional in authorization::Request, and add > an `UNKNOWN = 0;` enum value. See MESOS-4997 for details. -- 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=15211921#comment-15211921
]
Yong Tang commented on MESOS-4112:
--
Hi [~mcypark],
Any chance to take a look at the review request
https://reviews.apache.org/r/45070/
or any suggestions on the lib process test macros overall?
Feedbacks are greatly appreciated.
> 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] [Commented] (MESOS-5020) Drop `404 Not Found` and `307 Temporary Redirect` in the scheduler library.
[
https://issues.apache.org/jira/browse/MESOS-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15211124#comment-15211124
]
Yong Tang commented on MESOS-5020:
--
Hi [~anandmazumdar] [~vinodkone], I created a review request:
https://reviews.apache.org/r/45327/
Please take a look if you have time and let me know if there are any issues.
> Drop `404 Not Found` and `307 Temporary Redirect` in the scheduler library.
> ---
>
> Key: MESOS-5020
> URL: https://issues.apache.org/jira/browse/MESOS-5020
> Project: Mesos
> Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: mesosphere, newbie
>
> Currently, the scheduler library does not drop {{404 Not Found}} but treats
> them as {{Event::ERROR}}. The library can receive this if the master has not
> yet set up HTTP routes yet. The executor library already deals with this.
> Secondly, in some cases, the {{detector}} can detect a new master without the
> master realizing that it has been elected as the new master. In such cases,
> the master responds with {{307 Temporary Redirect}}. We would like to drop
> these status codes too instead of treating them as {{Event::ERROR}} too.
> https://github.com/apache/mesos/blob/master/src/scheduler/scheduler.cpp#L547
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5020) Drop `404 Not Found` and `307 Temporary Redirect` in the scheduler library.
[
https://issues.apache.org/jira/browse/MESOS-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-5020:
Assignee: Yong Tang
> Drop `404 Not Found` and `307 Temporary Redirect` in the scheduler library.
> ---
>
> Key: MESOS-5020
> URL: https://issues.apache.org/jira/browse/MESOS-5020
> Project: Mesos
> Issue Type: Improvement
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: mesosphere, newbie
>
> Currently, the scheduler library does not drop {{404 Not Found}} but treats
> them as {{Event::ERROR}}. The library can receive this if the master has not
> yet set up HTTP routes yet. The executor library already deals with this.
> Secondly, in some cases, the {{detector}} can detect a new master without the
> master realizing that it has been elected as the new master. In such cases,
> the master responds with {{307 Temporary Redirect}}. We would like to drop
> these status codes too instead of treating them as {{Event::ERROR}} too.
> https://github.com/apache/mesos/blob/master/src/scheduler/scheduler.cpp#L547
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5014) Call and Event Type enums in scheduler.proto should be optional
[ https://issues.apache.org/jira/browse/MESOS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210974#comment-15210974 ] Yong Tang commented on MESOS-5014: -- Hi [~vinodkone], I added a review request: https://reviews.apache.org/r/45317/ Let me know if there are any issues. > Call and Event Type enums in scheduler.proto should be optional > --- > > Key: MESOS-5014 > URL: https://issues.apache.org/jira/browse/MESOS-5014 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Yong Tang > > Having a 'required' Type enum has backwards compatibility issues when adding > new enum types. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5014) Call and Event Type enums in scheduler.proto should be optional
[ https://issues.apache.org/jira/browse/MESOS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-5014: Assignee: Yong Tang > Call and Event Type enums in scheduler.proto should be optional > --- > > Key: MESOS-5014 > URL: https://issues.apache.org/jira/browse/MESOS-5014 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Yong Tang > > Having a 'required' Type enum has backwards compatibility issues when adding > new enum types. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5015) Call and Event Type enums in executor.proto should be optional
[ https://issues.apache.org/jira/browse/MESOS-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210751#comment-15210751 ] Yong Tang commented on MESOS-5015: -- Hi [~vinodkone] Just created a review request: https://reviews.apache.org/r/45304/ Let me know if there are any issues. > Call and Event Type enums in executor.proto should be optional > -- > > Key: MESOS-5015 > URL: https://issues.apache.org/jira/browse/MESOS-5015 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Yong Tang > > Having a 'required' Type enum has backwards compatibility issues when adding > new enum types. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5015) Call and Event Type enums in executor.proto should be optional
[ https://issues.apache.org/jira/browse/MESOS-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-5015: Assignee: Yong Tang > Call and Event Type enums in executor.proto should be optional > -- > > Key: MESOS-5015 > URL: https://issues.apache.org/jira/browse/MESOS-5015 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Yong Tang > > Having a 'required' Type enum has backwards compatibility issues when adding > new enum types. See MESOS-4997 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4070) numify() handles negative numbers inconsistently.
[
https://issues.apache.org/jira/browse/MESOS-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15204889#comment-15204889
]
Yong Tang commented on MESOS-4070:
--
Ping [~jieyu], any feedback or can you shepherd this issue if possible?
> numify() handles negative numbers inconsistently.
> -
>
> Key: MESOS-4070
> URL: https://issues.apache.org/jira/browse/MESOS-4070
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Jie Yu
>Assignee: Yong Tang
> Labels: tech-debt
>
> As pointed by [~neilc] in this review:
> https://reviews.apache.org/r/40988
> {noformat}
> Try num2 = numify("-10");
> EXPECT_SOME_EQ(-10, num2);
> // TODO(neilc): This is inconsistent with the handling of non-hex numbers.
> EXPECT_ERROR(numify("-0x10"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4621:
Assignee: Yong Tang
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4033) Add a commit hook for non-ascii charachters
[ https://issues.apache.org/jira/browse/MESOS-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yong Tang reassigned MESOS-4033: Assignee: Yong Tang > Add a commit hook for non-ascii charachters > --- > > Key: MESOS-4033 > URL: https://issues.apache.org/jira/browse/MESOS-4033 > Project: Mesos > Issue Type: Task >Reporter: Alexander Rukletsov >Assignee: Yong Tang >Priority: Minor > Labels: mesosphere > > Non-ascii characters invisible in some editors may sneak into the codebase > (see e.g. https://reviews.apache.org/r/40799/). To avoid this, a pre-commit > hook can be added. > Quick searching suggested a simple perl script: > https://superuser.com/questions/417305/how-can-i-identify-non-ascii-characters-from-the-shell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197471#comment-15197471
]
Yong Tang edited comment on MESOS-4621 at 3/16/16 3:11 PM:
---
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway:
# --enable-optimize : [enable_optimize=yes]
# --enable-optimize=yes : [enable_optimize=yes]
# --enable-optimize=no : [enable_optimize=no]
# --disable-optimize : [enable_optimize=no]
was (Author: yongtang):
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway.
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4093) Unify namespace order in mesos code
[
https://issues.apache.org/jira/browse/MESOS-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4093:
Assignee: Yong Tang
> Unify namespace order in mesos code
> ---
>
> Key: MESOS-4093
> URL: https://issues.apache.org/jira/browse/MESOS-4093
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Yong Tang
>
> This is from code review for https://reviews.apache.org/r/40995/
> There is no rule for where to put std namespace.
> Style 1)
> {code}
> using process::Clock;
> using process::Future;
> using process::Message;
> using process::PID;
> using std::vector;
> {code}
> Style 2)
> {code}
> using std::string;
> using std::vector;
> using google::protobuf::RepeatedPtrField;
> using mesos::internal::master::Master;
> using mesos::internal::slave::Slave;
> using mesos::quota::QuotaInfo;
> using process::Future;
> using process::PID;
> using process::http::BadRequest;
> using process::http::Conflict;
> using process::http::OK;
> using process::http::Response;
> {code}
> I think that we should always follow style 2) to make sure putting std at the
> beginning as it is system library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4070) numify() handles negative numbers inconsistently.
[
https://issues.apache.org/jira/browse/MESOS-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4070:
Assignee: Yong Tang
> numify() handles negative numbers inconsistently.
> -
>
> Key: MESOS-4070
> URL: https://issues.apache.org/jira/browse/MESOS-4070
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Jie Yu
>Assignee: Yong Tang
> Labels: tech-debt
>
> As pointed by [~neilc] in this review:
> https://reviews.apache.org/r/40988
> {noformat}
> Try num2 = numify("-10");
> EXPECT_SOME_EQ(-10, num2);
> // TODO(neilc): This is inconsistent with the handling of non-hex numbers.
> EXPECT_ERROR(numify("-0x10"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4033) Add a commit hook for non-ascii charachters
[ https://issues.apache.org/jira/browse/MESOS-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201573#comment-15201573 ] Yong Tang edited comment on MESOS-4033 at 3/18/16 2:50 PM: --- Hi [~alexr] [~bernd-mesos], I added a review request to address this issue: https://reviews.apache.org/r/45033/ Would appreciate any feedbacks or comments. was (Author: yongtang): Hi [~alexr] [~bernd-mesos], I added a review request to address this issue: https://reviews.apache.org/r/45033/ Would appreciate for any feedbacks or comments. > Add a commit hook for non-ascii charachters > --- > > Key: MESOS-4033 > URL: https://issues.apache.org/jira/browse/MESOS-4033 > Project: Mesos > Issue Type: Task >Reporter: Alexander Rukletsov >Assignee: Yong Tang >Priority: Minor > Labels: mesosphere > > Non-ascii characters invisible in some editors may sneak into the codebase > (see e.g. https://reviews.apache.org/r/40799/). To avoid this, a pre-commit > hook can be added. > Quick searching suggested a simple perl script: > https://superuser.com/questions/417305/how-can-i-identify-non-ascii-characters-from-the-shell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4033) Add a commit hook for non-ascii charachters
[ https://issues.apache.org/jira/browse/MESOS-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201573#comment-15201573 ] Yong Tang commented on MESOS-4033: -- Hi [~alexr] [~bernd-mesos], I added a review request to address this issue: https://reviews.apache.org/r/45033/ Would appreciate for any feedbacks or comments. > Add a commit hook for non-ascii charachters > --- > > Key: MESOS-4033 > URL: https://issues.apache.org/jira/browse/MESOS-4033 > Project: Mesos > Issue Type: Task >Reporter: Alexander Rukletsov >Assignee: Yong Tang >Priority: Minor > Labels: mesosphere > > Non-ascii characters invisible in some editors may sneak into the codebase > (see e.g. https://reviews.apache.org/r/40799/). To avoid this, a pre-commit > hook can be added. > Quick searching suggested a simple perl script: > https://superuser.com/questions/417305/how-can-i-identify-non-ascii-characters-from-the-shell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4070) numify() handles negative numbers inconsistently.
[
https://issues.apache.org/jira/browse/MESOS-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15200776#comment-15200776
]
Yong Tang commented on MESOS-4070:
--
[~jieyu] I just submitted a review request for this issue:
https://reviews.apache.org/r/45011/
Would you mind shepherd this?
> numify() handles negative numbers inconsistently.
> -
>
> Key: MESOS-4070
> URL: https://issues.apache.org/jira/browse/MESOS-4070
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Jie Yu
>Assignee: Yong Tang
> Labels: tech-debt
>
> As pointed by [~neilc] in this review:
> https://reviews.apache.org/r/40988
> {noformat}
> Try num2 = numify("-10");
> EXPECT_SOME_EQ(-10, num2);
> // TODO(neilc): This is inconsistent with the handling of non-hex numbers.
> EXPECT_ERROR(numify("-0x10"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197471#comment-15197471
]
Yong Tang edited comment on MESOS-4621 at 3/16/16 3:12 PM:
---
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replacing "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway:
# --enable-optimize : [enable_optimize=yes]
# --enable-optimize=yes : [enable_optimize=yes]
# --enable-optimize=no : [enable_optimize=no]
# --disable-optimize : [enable_optimize=no]
was (Author: yongtang):
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway:
# --enable-optimize : [enable_optimize=yes]
# --enable-optimize=yes : [enable_optimize=yes]
# --enable-optimize=no : [enable_optimize=no]
# --disable-optimize : [enable_optimize=no]
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197746#comment-15197746
]
Yong Tang commented on MESOS-4621:
--
I take a look at the review request. Feel like it is probably too big to be
reviewed in one pass. Maybe it could be better if it is decomposed into several
RRs?
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4621) --disable-optimize triggers optimized builds.
[
https://issues.apache.org/jira/browse/MESOS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197471#comment-15197471
]
Yong Tang commented on MESOS-4621:
--
Added a review request:
https://reviews.apache.org/r/44911/
The issue was that, in original configure.ac,
{code}
AC_ARG_ENABLE([optimize],
AS_HELP_STRING(...),
[enable_optimize=yes], [])
{code}
The third field is "action-if-present", it could be
# --enable-optimize
# --enable-optimize=yes
# --enable-optimize=no
# --disable-optimize
Yet in the original code it always set "[enable_optimize=yes]".
This could be fixed by simply replace "[enable_optimize=yes]" with "[]" as by
default AC_ARG_ENABLE will always set the value of "enable_optimize" correctly
anyway.
> --disable-optimize triggers optimized builds.
> -
>
> Key: MESOS-4621
> URL: https://issues.apache.org/jira/browse/MESOS-4621
> Project: Mesos
> Issue Type: Bug
>Reporter: Till Toenshoff
>Assignee: Yong Tang
>Priority: Minor
>
> The toggle-logic of the build configuration argument {{optimize}} appears to
> be implemented incorrectly. When using the perfectly legal invocation;
> {noformat}
> ../configure --disable-optimize
> {noformat}
> What you get here is enabled optimizing {{O2}}.
> {noformat}
> ccache g++ -Qunused-arguments -fcolor-diagnostics
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBCURL=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../../3rdparty/libprocess/3rdparty
> -I../../../../3rdparty/libprocess/3rdparty/stout/include -Iprotobuf-2.5.0/src
> -Igmock-1.7.0/gtest/include -Igmock-1.7.0/include -isystem boost-1.53.0
> -Ipicojson-1.3.0 -DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -Iglog-0.3.3/src
> -I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -O2 -Wno-unused-local-typedef -std=c++11
> -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1 -DGTEST_LANG_CXX11 -MT
> stout_tests-flags_tests.o -MD -MP -MF .deps/stout_tests-flags_tests.Tpo -c -o
> stout_tests-flags_tests.o `test -f 'stout/tests/flags_tests.cpp' || echo
> '../../../../3rdparty/libprocess/3rdparty/'`stout/tests/flags_tests.cpp
> {noformat}
> It seems more straightforward to actually disable optimizing for the above
> argument.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4112) Clean up libprocess gtest macros
[
https://issues.apache.org/jira/browse/MESOS-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4112:
Assignee: Yong Tang
> 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] [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=15202511#comment-15202511
]
Yong Tang commented on MESOS-4112:
--
Hi [~mcypark], I created a review request:
https://reviews.apache.org/r/45070/
and would appreciate if you have a chance to take a look.
In this review request I get the item (1) and (2) in your list done. For item
(3) and (4) I would like your confirmation before I move forward. Let me know
what you think and I will get it done. Thanks!
> 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] [Commented] (MESOS-4954) URI fetcher error message if plugin is not found is mis-leading.
[
https://issues.apache.org/jira/browse/MESOS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15196691#comment-15196691
]
Yong Tang commented on MESOS-4954:
--
Added the review request:
https://reviews.apache.org/r/44883/
> URI fetcher error message if plugin is not found is mis-leading.
>
>
> Key: MESOS-4954
> URL: https://issues.apache.org/jira/browse/MESOS-4954
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: newbie
>
> In {{src/uri/fetcher.cpp}}, if we are unable to create a plugin, we skip it
> but we log an erroneous misleading message:
> {code}
> // NOTE: We skip the plugin if it cannot be created, instead of
> // returning an Error so that we can still use other plugins.
> LOG(ERROR) << "Failed to create URI fetcher plugin "
> << "'" << name << "': " << plugin.error();
> {code}
> Ideally, it should be at best a {{LOG(INFO)}} with it clearly specifying that
> the relevant plugin was skipped since it was not found.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4954) URI fetcher error message if plugin is not found is mis-leading.
[
https://issues.apache.org/jira/browse/MESOS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4954:
Assignee: Yong Tang
> URI fetcher error message if plugin is not found is mis-leading.
>
>
> Key: MESOS-4954
> URL: https://issues.apache.org/jira/browse/MESOS-4954
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: newbie
>
> In {{src/uri/fetcher.cpp}}, if we are unable to create a plugin, we skip it
> but we log an erroneous misleading message:
> {code}
> // NOTE: We skip the plugin if it cannot be created, instead of
> // returning an Error so that we can still use other plugins.
> LOG(ERROR) << "Failed to create URI fetcher plugin "
> << "'" << name << "': " << plugin.error();
> {code}
> Ideally, it should be at best a {{LOG(INFO)}} with it clearly specifying that
> the relevant plugin was skipped since it was not found.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4906) Upgrade to clang-format-3.8.
[
https://issues.apache.org/jira/browse/MESOS-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192118#comment-15192118
]
Yong Tang commented on MESOS-4906:
--
Hi [~mcypark] just added a review request:
https://reviews.apache.org/r/44758/
Please let me know if there are any issues.
> Upgrade to clang-format-3.8.
>
>
> Key: MESOS-4906
> URL: https://issues.apache.org/jira/browse/MESOS-4906
> Project: Mesos
> Issue Type: Task
> Components: technical debt
>Reporter: Michael Park
>Assignee: Yong Tang
>
> The newly introduced {{AlignAfterOpenBracket: AlwaysBreak}} option in
> {{clang-format-3.8}} closes the largest gap we have between ClangFormat and
> our style guide. That is, avoiding "jaggedness" in function calls. This is a
> big win, and is definitely worth migrating for.
> As part of this ticket, we should:
> 1. Announce to the dev list that our default {{clang-format}} configuration,
> as well as the recommended version is being upgraded.
> 2. Update the {{clang-format}} configuration.
> 3. Update the
> [ClangFormat|http://mesos.apache.org/documentation/latest/clang-format/]
> documentation for Mesos
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4906) Upgrade to clang-format-3.8.
[
https://issues.apache.org/jira/browse/MESOS-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4906:
Assignee: Yong Tang
> Upgrade to clang-format-3.8.
>
>
> Key: MESOS-4906
> URL: https://issues.apache.org/jira/browse/MESOS-4906
> Project: Mesos
> Issue Type: Task
> Components: technical debt
>Reporter: Michael Park
>Assignee: Yong Tang
>
> The newly introduced {{AlignAfterOpenBracket: AlwaysBreak}} option in
> {{clang-format-3.8}} closes the largest gap we have between ClangFormat and
> our style guide. That is, avoiding "jaggedness" in function calls. This is a
> big win, and is definitely worth migrating for.
> As part of this ticket, we should:
> 1. Announce to the dev list that our default {{clang-format}} configuration,
> as well as the recommended version is being upgraded.
> 2. Update the {{clang-format}} configuration.
> 3. Update the
> [ClangFormat|http://mesos.apache.org/documentation/latest/clang-format/]
> documentation for Mesos
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4868) PersistentVolumeTests do not need to set up ACLs.
[
https://issues.apache.org/jira/browse/MESOS-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15180690#comment-15180690
]
Yong Tang commented on MESOS-4868:
--
Added Review Request: https://reviews.apache.org/r/44408/
> PersistentVolumeTests do not need to set up ACLs.
> -
>
> Key: MESOS-4868
> URL: https://issues.apache.org/jira/browse/MESOS-4868
> Project: Mesos
> Issue Type: Improvement
> Components: technical debt, test
>Reporter: Joseph Wu
>Assignee: Yong Tang
> Labels: mesosphere, newbie, test
>
> The {{PersistentVolumeTest}} s have a custom helper for setting up ACLs in
> the {{master::Flags}}:
> {code}
> ACLs acls;
> hashset roles;
> foreach (const FrameworkInfo& framework, frameworks) {
> mesos::ACL::RegisterFramework* acl = acls.add_register_frameworks();
> acl->mutable_principals()->add_values(framework.principal());
> acl->mutable_roles()->add_values(framework.role());
> roles.insert(framework.role());
> }
> flags.acls = acls;
> flags.roles = strings::join(",", roles);
> {code}
> This is no longer necessary with implicit roles.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4868) PersistentVolumeTests do not need to set up ACLs.
[
https://issues.apache.org/jira/browse/MESOS-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4868:
Assignee: Yong Tang
> PersistentVolumeTests do not need to set up ACLs.
> -
>
> Key: MESOS-4868
> URL: https://issues.apache.org/jira/browse/MESOS-4868
> Project: Mesos
> Issue Type: Improvement
> Components: technical debt, test
>Reporter: Joseph Wu
>Assignee: Yong Tang
> Labels: mesosphere, newbie, test
>
> The {{PersistentVolumeTest}} s have a custom helper for setting up ACLs in
> the {{master::Flags}}:
> {code}
> ACLs acls;
> hashset roles;
> foreach (const FrameworkInfo& framework, frameworks) {
> mesos::ACL::RegisterFramework* acl = acls.add_register_frameworks();
> acl->mutable_principals()->add_values(framework.principal());
> acl->mutable_roles()->add_values(framework.role());
> roles.insert(framework.role());
> }
> flags.acls = acls;
> flags.roles = strings::join(",", roles);
> {code}
> This is no longer necessary with implicit roles.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4807) IOTest.BufferedRead writes to the current directory
[
https://issues.apache.org/jira/browse/MESOS-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15179508#comment-15179508
]
Yong Tang commented on MESOS-4807:
--
Added Review Request:
https://reviews.apache.org/r/44380/
> IOTest.BufferedRead writes to the current directory
> ---
>
> Key: MESOS-4807
> URL: https://issues.apache.org/jira/browse/MESOS-4807
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, test
>Reporter: Benjamin Bannier
>Assignee: Yong Tang
>Priority: Minor
> Labels: newbie, parallel-tests
>
> libprocess's {{IOTest.BufferedRead}} writes to the current directory. This is
> bad for a number of reasons, e.g.,
> * should the test fail data might be leaked to random locations,
> * the test cannot be executed from a write-only directory, or
> * executing the same test in parallel would race on the existence of the
> created file, and show bogus behavior.
> The test should probably be executed from a temporary directory, e.g., via
> stout's {{TemporaryDirectoryTest}} fixture.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4807) IOTest.BufferedRead writes to the current directory
[
https://issues.apache.org/jira/browse/MESOS-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4807:
Assignee: Yong Tang
> IOTest.BufferedRead writes to the current directory
> ---
>
> Key: MESOS-4807
> URL: https://issues.apache.org/jira/browse/MESOS-4807
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, test
>Reporter: Benjamin Bannier
>Assignee: Yong Tang
>Priority: Minor
> Labels: newbie, parallel-tests
>
> libprocess's {{IOTest.BufferedRead}} writes to the current directory. This is
> bad for a number of reasons, e.g.,
> * should the test fail data might be leaked to random locations,
> * the test cannot be executed from a write-only directory, or
> * executing the same test in parallel would race on the existence of the
> created file, and show bogus behavior.
> The test should probably be executed from a temporary directory, e.g., via
> stout's {{TemporaryDirectoryTest}} fixture.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4583) Rename `examples/event_call_framework.cpp` to `examples/test_http_framework.cpp`
[
https://issues.apache.org/jira/browse/MESOS-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15175757#comment-15175757
]
Yong Tang commented on MESOS-4583:
--
Added a Review Request:
https://reviews.apache.org/r/44266/
> Rename `examples/event_call_framework.cpp` to
> `examples/test_http_framework.cpp`
>
>
> Key: MESOS-4583
> URL: https://issues.apache.org/jira/browse/MESOS-4583
> Project: Mesos
> Issue Type: Bug
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: mesosphere, newbie
>
> We already have {{examples/test_framework.cpp}} for testing {{PID}} based
> frameworks. We would ideally want to rename {{event_call_framework}} to
> correctly reflect that it's an example for HTTP based framework.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4583) Rename `examples/event_call_framework.cpp` to `examples/test_http_framework.cpp`
[
https://issues.apache.org/jira/browse/MESOS-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4583:
Assignee: Yong Tang
> Rename `examples/event_call_framework.cpp` to
> `examples/test_http_framework.cpp`
>
>
> Key: MESOS-4583
> URL: https://issues.apache.org/jira/browse/MESOS-4583
> Project: Mesos
> Issue Type: Bug
>Reporter: Anand Mazumdar
>Assignee: Yong Tang
> Labels: mesosphere, newbie
>
> We already have {{examples/test_framework.cpp}} for testing {{PID}} based
> frameworks. We would ideally want to rename {{event_call_framework}} to
> correctly reflect that it's an example for HTTP based framework.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4792) Remove src/common/date_utils.{c,h}pp
[
https://issues.apache.org/jira/browse/MESOS-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173384#comment-15173384
]
Yong Tang commented on MESOS-4792:
--
The review request seems to have been merged. Thanks [~neilc] for the review.
> Remove src/common/date_utils.{c,h}pp
>
>
> Key: MESOS-4792
> URL: https://issues.apache.org/jira/browse/MESOS-4792
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Assignee: Yong Tang
>Priority: Trivial
> Labels: mesosphere, newbie, tech-debt
>
> AFAICT this is unused.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4792) Remove src/common/date_utils.{c,h}pp
[
https://issues.apache.org/jira/browse/MESOS-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171152#comment-15171152
]
Yong Tang commented on MESOS-4792:
--
Seems to be an easy fix. Just created a review request:
https://reviews.apache.org/r/44147/
> Remove src/common/date_utils.{c,h}pp
>
>
> Key: MESOS-4792
> URL: https://issues.apache.org/jira/browse/MESOS-4792
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Assignee: Yong Tang
>Priority: Trivial
> Labels: mesosphere, newbie, tech-debt
>
> AFAICT this is unused.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4792) Remove src/common/date_utils.{c,h}pp
[
https://issues.apache.org/jira/browse/MESOS-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4792:
Assignee: Yong Tang
> Remove src/common/date_utils.{c,h}pp
>
>
> Key: MESOS-4792
> URL: https://issues.apache.org/jira/browse/MESOS-4792
> Project: Mesos
> Issue Type: Improvement
> Components: general
>Reporter: Neil Conway
>Assignee: Yong Tang
>Priority: Trivial
> Labels: mesosphere, newbie, tech-debt
>
> AFAICT this is unused.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4602) Invalid usage of ATOMIC_FLAG_INIT in member initialization
[
https://issues.apache.org/jira/browse/MESOS-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163399#comment-15163399
]
Yong Tang commented on MESOS-4602:
--
The patch has been applied. Thanks [~bbannier] and [~tillt] for reviews.
> Invalid usage of ATOMIC_FLAG_INIT in member initialization
> --
>
> Key: MESOS-4602
> URL: https://issues.apache.org/jira/browse/MESOS-4602
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Benjamin Bannier
>Assignee: Yong Tang
> Labels: newbie, tech-debt
>
> MESOS-2925 fixed a few instances where {{ATOMIC_FLAG_INIT}} was used in
> initializer lists, but missed to fix
> {{3rdparty/libprocess/src/libevent_ssl_socket.cpp}} (even though the
> corresponding header was touched).
> There, {{LibeventSSLSocketImpl}}'s {{lock}} member is still (incorrectly)
> initialized in initializer lists, even though the member is already
> initialized in the class declaration, so it appears they should be dropped.
> Clang from trunk incorrectly diagnoses the initializations in the initializer
> lists as benign redundant braces in initialization of a scalar, but they
> should be fixed for the reasons stated in MESOS-2925.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4602) Invalid usage of ATOMIC_FLAG_INIT in member initialization
[
https://issues.apache.org/jira/browse/MESOS-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158047#comment-15158047
]
Yong Tang commented on MESOS-4602:
--
That seems to be an easy fix. Just submitted a review request:
https://reviews.apache.org/r/43859/
> Invalid usage of ATOMIC_FLAG_INIT in member initialization
> --
>
> Key: MESOS-4602
> URL: https://issues.apache.org/jira/browse/MESOS-4602
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Benjamin Bannier
>Assignee: Yong Tang
> Labels: newbie, tech-debt
>
> MESOS-2925 fixed a few instances where {{ATOMIC_FLAG_INIT}} was used in
> initializer lists, but missed to fix
> {{3rdparty/libprocess/src/libevent_ssl_socket.cpp}} (even though the
> corresponding header was touched).
> There, {{LibeventSSLSocketImpl}}'s {{lock}} member is still (incorrectly)
> initialized in initializer lists, even though the member is already
> initialized in the class declaration, so it appears they should be dropped.
> Clang from trunk incorrectly diagnoses the initializations in the initializer
> lists as benign redundant braces in initialization of a scalar, but they
> should be fixed for the reasons stated in MESOS-2925.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-4601) Don't dump stack trace on failure to bind()
[
https://issues.apache.org/jira/browse/MESOS-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang reassigned MESOS-4601:
Assignee: Yong Tang
> Don't dump stack trace on failure to bind()
> ---
>
> Key: MESOS-4601
> URL: https://issues.apache.org/jira/browse/MESOS-4601
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Yong Tang
> Labels: errorhandling, libprocess, mesosphere, newbie
>
> We should do {{EXIT(EXIT_FAILURE)}} rather than {{LOG(FATAL)}}, both for this
> code path and a few other expected error conditions in libprocess network
> initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4601) Don't dump stack trace on failure to bind()
[
https://issues.apache.org/jira/browse/MESOS-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134107#comment-15134107
]
Yong Tang commented on MESOS-4601:
--
Will take a look at this issue as I have some free time in the next couple of
weeks.
> Don't dump stack trace on failure to bind()
> ---
>
> Key: MESOS-4601
> URL: https://issues.apache.org/jira/browse/MESOS-4601
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Assignee: Yong Tang
> Labels: errorhandling, libprocess, mesosphere, newbie
>
> We should do {{EXIT(EXIT_FAILURE)}} rather than {{LOG(FATAL)}}, both for this
> code path and a few other expected error conditions in libprocess network
> initialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3219) Slave recovery issues with Docker containerizer
[ https://issues.apache.org/jira/browse/MESOS-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15036024#comment-15036024 ] Yong Tang commented on MESOS-3219: -- If your systems could assume that the container can always run, then a (partially) workaround is to have a shell script to constantly restart mesos slave in a loop within the container. In this way, the shell script will be served as the foreground process so the container will not die. If mesos slave process itself dies then at least the shell script will restart and recover correctly. That obviously is not a complete solution but it may help in certain situations. > Slave recovery issues with Docker containerizer > --- > > Key: MESOS-3219 > URL: https://issues.apache.org/jira/browse/MESOS-3219 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Anderson >Assignee: Timothy Chen >Priority: Minor > > I'm working on setting up a Mesos environment with the > Docker containerizer and can't seem to get the recovery feature > working. I'm running CoreOS, so the slave processes themselves are > containerized. I have no issues running jobs without the recovery > features enabled, but all jobs fail to boot when I add the following > flags: > MESOS_DOCKER_KILL_ORPHANS=false > MESOS_DOCKER_MESOS_IMAGE=myrepo/my-slave-container > Inspecting the Docker images and their log output reveals that the > container invocation appears to be flawed - see this gist, which shows the > arguments as retrieved via `docker inspect` as well as the failed container's > log output: > https://gist.github.com/banjiewen/a2dc1784a82ed87edd6b > The containerizer is attempting to invoke an unquoted command via > `/bin/sh -c`, which, predictably, fails to pass the complete command. > This results in the error message shown in the second file in the > linked gist. > This is reproducible manually; quoting the arguments to `/bin/sh -c` > results in success (at least, it correctly receives the supplied > arguments). > The slave container itself is not logging anything of interest. > It's possible that my instance is configured incorrectly as well; the > documentation here is a bit vague and there aren't many examples on the web. > I'm running Mesos 0.23.0 installed via http://repos.mesosphere.io/ in an > Ubuntu 14.04 container. CoreOS is at the latest stable (717.3.0) which gives > a Docker version at about 1.6.2. > I'm happy to provide more details if necessary. Cheers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3219) Slave recovery issues with Docker containerizer
[ https://issues.apache.org/jira/browse/MESOS-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008780#comment-15008780 ] Yong Tang commented on MESOS-3219: -- Hi [~tnachen] I encountered a similar issue when I tried to pass --docker_mesos_image=mesosphere/mesos-slave:0.25.0-0.2.70.ubuntu1404 which is the same as described by the email (CC [~gregory90]) thread in: https://www.mail-archive.com/user@mesos.apache.org/msg04975.html I am wondering if there is any progress with respect to this issue? I am happy to provide more details or helps if needed. Thanks > Slave recovery issues with Docker containerizer > --- > > Key: MESOS-3219 > URL: https://issues.apache.org/jira/browse/MESOS-3219 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Anderson >Assignee: Timothy Chen >Priority: Minor > > I'm working on setting up a Mesos environment with the > Docker containerizer and can't seem to get the recovery feature > working. I'm running CoreOS, so the slave processes themselves are > containerized. I have no issues running jobs without the recovery > features enabled, but all jobs fail to boot when I add the following > flags: > MESOS_DOCKER_KILL_ORPHANS=false > MESOS_DOCKER_MESOS_IMAGE=myrepo/my-slave-container > Inspecting the Docker images and their log output reveals that the > container invocation appears to be flawed - see this gist, which shows the > arguments as retrieved via `docker inspect` as well as the failed container's > log output: > https://gist.github.com/banjiewen/a2dc1784a82ed87edd6b > The containerizer is attempting to invoke an unquoted command via > `/bin/sh -c`, which, predictably, fails to pass the complete command. > This results in the error message shown in the second file in the > linked gist. > This is reproducible manually; quoting the arguments to `/bin/sh -c` > results in success (at least, it correctly receives the supplied > arguments). > The slave container itself is not logging anything of interest. > It's possible that my instance is configured incorrectly as well; the > documentation here is a bit vague and there aren't many examples on the web. > I'm running Mesos 0.23.0 installed via http://repos.mesosphere.io/ in an > Ubuntu 14.04 container. CoreOS is at the latest stable (717.3.0) which gives > a Docker version at about 1.6.2. > I'm happy to provide more details if necessary. Cheers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3797) Support replacing Zookeeper with Consul
Yong Tang created MESOS-3797: Summary: Support replacing Zookeeper with Consul Key: MESOS-3797 URL: https://issues.apache.org/jira/browse/MESOS-3797 Project: Mesos Issue Type: Improvement Components: leader election Reporter: Yong Tang Currently Mesos only support Zookeeper for leader election. While Zookeeper has been widely used it is not actively developed and the configuration of Zookeeper is often cumbersome or difficult. There is already an ongoing MESOS-1806 which would replace Zookeeper with etcd. It would be great if Mesos could support replacing Zookeeper with Consul for its ease of deployment. While MESOS-3574 proposed Mesos to do its own leader election and failure detection, replacing Zookeeper with Consul as a short term solution will really benefit a lot of existing Mesos users that want to avoid the dependency of Zookeeper deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3797) Support replacing Zookeeper with Consul
[ https://issues.apache.org/jira/browse/MESOS-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971258#comment-14971258 ] Yong Tang commented on MESOS-3797: -- Replacing Mesos with Consul could be part of MESOS-3574, and a short term solution before the implementation of (no-dependency) leader election in Mesos. > Support replacing Zookeeper with Consul > --- > > Key: MESOS-3797 > URL: https://issues.apache.org/jira/browse/MESOS-3797 > Project: Mesos > Issue Type: Improvement > Components: leader election >Reporter: Yong Tang > > Currently Mesos only support Zookeeper for leader election. While Zookeeper > has been widely used it is not actively developed and the configuration of > Zookeeper is often cumbersome or difficult. > There is already an ongoing MESOS-1806 which would replace Zookeeper with > etcd. It would be great if Mesos could support replacing Zookeeper with > Consul for its ease of deployment. > While MESOS-3574 proposed Mesos to do its own leader election and failure > detection, replacing Zookeeper with Consul as a short term solution will > really benefit a lot of existing Mesos users that want to avoid the > dependency of Zookeeper deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3797) Support replacing Zookeeper with Consul
[ https://issues.apache.org/jira/browse/MESOS-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971248#comment-14971248 ] Yong Tang commented on MESOS-3797: -- The implementation of replacing Zookeeper with etcd could help the implementation of replacing Zookeeper with Consul. > Support replacing Zookeeper with Consul > --- > > Key: MESOS-3797 > URL: https://issues.apache.org/jira/browse/MESOS-3797 > Project: Mesos > Issue Type: Improvement > Components: leader election >Reporter: Yong Tang > > Currently Mesos only support Zookeeper for leader election. While Zookeeper > has been widely used it is not actively developed and the configuration of > Zookeeper is often cumbersome or difficult. > There is already an ongoing MESOS-1806 which would replace Zookeeper with > etcd. It would be great if Mesos could support replacing Zookeeper with > Consul for its ease of deployment. > While MESOS-3574 proposed Mesos to do its own leader election and failure > detection, replacing Zookeeper with Consul as a short term solution will > really benefit a lot of existing Mesos users that want to avoid the > dependency of Zookeeper deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3574) Support replacing ZooKeeper with replicated log
[ https://issues.apache.org/jira/browse/MESOS-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971266#comment-14971266 ] Yong Tang commented on MESOS-3574: -- Created MESOS-3797 to capture implementation of replacing Zookeeper with Consul. In the short term a lot of users would like to remove the dependency of Zookeeper (by either replace it with etcd, or with Consul). > Support replacing ZooKeeper with replicated log > --- > > Key: MESOS-3574 > URL: https://issues.apache.org/jira/browse/MESOS-3574 > Project: Mesos > Issue Type: Improvement > Components: leader election, replicated log >Reporter: Neil Conway > Labels: mesosphere > > It would be useful to support using the replicated log without also requiring > ZooKeeper to be running. This would simplify the process of > configuring/operating a high-availability configuration of Mesos. > At least three things would need to be done: > 1. Abstract away the stuff we use Zk for into an interface that can be > implemented (e.g., by etcd, consul, rep-log, or Zk). This might be done > already as part of [MESOS-1806] > 2. Enhance the replicated log to be able to do its own leader election + > failure detection (to decide when the current master is down). > 3. Validate replicated log performance to ensure it is adequate (per Joris, > likely needs some significant work) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
[
https://issues.apache.org/jira/browse/MESOS-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960954#comment-14960954
]
Yong Tang commented on MESOS-3738:
--
Thanks. Was going to spend more time to investigate this issue but is glad a
fix is already there.
> Mesos health check is invoked incorrectly when Mesos slave is within the
> docker container
> -
>
> Key: MESOS-3738
> URL: https://issues.apache.org/jira/browse/MESOS-3738
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.0:
> Client:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Server:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Host: Ubuntu 14.04
> Container: Debian 8.1 + Java-7
>Reporter: Yong Tang
>Assignee: haosdent
> Attachments: MESOS-3738-0_23_1.patch, MESOS-3738-0_24_1.patch,
> MESOS-3738-0_25_0.patch
>
>
> When Mesos slave is within the container, the COMMAND health check from
> Marathon is invoked incorrectly.
> In such a scenario, the sandbox directory (instead of the
> launcher/health-check directory) is used. This result in an error with the
> container.
> Command to invoke the Mesos slave container:
> sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
> /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
> -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
> mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
> --executor_registration_timeout=5mins --docker_stop_timeout=10secs
> --launcher=posix
> Marathon JSON file:
> {
> "id": "ubuntu",
> "container":
> {
> "type": "DOCKER",
> "docker":
> {
> "image": "ubuntu",
> "network": "BRIDGE",
> "parameters": []
> }
> },
> "args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
> "uris": [],
> "healthChecks":
> [
> {
> "protocol": "COMMAND",
> "command": { "value": "echo Success" },
> "gracePeriodSeconds": 3000,
> "intervalSeconds": 5,
> "timeoutSeconds": 5,
> "maxConsecutiveFailures": 300
> }
> ],
> "instances": 1
> }
> STDOUT:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> Registered docker executor on b01e2e75afcb
> Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> 1
> Launching health check process:
> /tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f/mesos-health-check
> --executor=(1)@10.2.1.7:40695
> --health_check_json={"command":{"shell":true,"value":"docker exec
> mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f
> sh -c \" echo Success
> \""},"consecutive_failures":300,"delay_seconds":0.0,"grace_period_seconds":3000.0,"interval_seconds":5.0,"timeout_seconds":5.0}
> --task_id=ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> Health check process launched at pid: 94
> 1
> 1
> 1
> 1
> 1
> STDERR:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stderr
> I1014 23:15:58.12795056 exec.cpp:134] Version: 0.25.0
> I1014 23:15:58.13062762 exec.cpp:208] Executor registered on slave
> e20f8959-cd9f-40ae-987d-809401309361-S0
> WARNING: Your kernel does not
[jira] [Commented] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
[
https://issues.apache.org/jira/browse/MESOS-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959702#comment-14959702
]
Yong Tang commented on MESOS-3738:
--
A quick workaround for this issue is to pass
--executor_environment_variables=executor.json
where executor.json consists of MESOS_LAUNCHER_DIR:
{"MESOS_LAUNCHER_DIR": "/usr/libexec/mesos"}
Though this is just a workaround. A fix for this issue is still needed in Mesos
source.
> Mesos health check is invoked incorrectly when Mesos slave is within the
> docker container
> -
>
> Key: MESOS-3738
> URL: https://issues.apache.org/jira/browse/MESOS-3738
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.0:
> Client:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Server:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Host: Ubuntu 14.04
> Container: Debian 8.1 + Java-7
>Reporter: Yong Tang
>Assignee: haosdent
>
> When Mesos slave is within the container, the COMMAND health check from
> Marathon is invoked incorrectly.
> In such a scenario, the sandbox directory (instead of the
> launcher/health-check directory) is used. This result in an error with the
> container.
> Command to invoke the Mesos slave container:
> sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
> /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
> -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
> mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
> --executor_registration_timeout=5mins --docker_stop_timeout=10secs
> --launcher=posix
> Marathon JSON file:
> {
> "id": "ubuntu",
> "container":
> {
> "type": "DOCKER",
> "docker":
> {
> "image": "ubuntu",
> "network": "BRIDGE",
> "parameters": []
> }
> },
> "args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
> "uris": [],
> "healthChecks":
> [
> {
> "protocol": "COMMAND",
> "command": { "value": "echo Success" },
> "gracePeriodSeconds": 3000,
> "intervalSeconds": 5,
> "timeoutSeconds": 5,
> "maxConsecutiveFailures": 300
> }
> ],
> "instances": 1
> }
> STDOUT:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> Registered docker executor on b01e2e75afcb
> Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> 1
> Launching health check process:
> /tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f/mesos-health-check
> --executor=(1)@10.2.1.7:40695
> --health_check_json={"command":{"shell":true,"value":"docker exec
> mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f
> sh -c \" echo Success
> \""},"consecutive_failures":300,"delay_seconds":0.0,"grace_period_seconds":3000.0,"interval_seconds":5.0,"timeout_seconds":5.0}
> --task_id=ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> Health check process launched at pid: 94
> 1
> 1
> 1
> 1
> 1
> STDERR:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stderr
> I1014 23:15:58.12795056 exec.cpp:134] Version: 0.25.0
> I1014 23:15:58.13062762 exec.cpp:208] Executor registered on slave
[jira] [Commented] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
[
https://issues.apache.org/jira/browse/MESOS-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14958274#comment-14958274
]
Yong Tang commented on MESOS-3738:
--
Tried to pass environmental variable MESOS_LAUNCHER_DIR with
sudo docker run -e MESOS_LAUNCHER_DIR=q/usr/libexec/mesos ...
but got the same result.
It seems that in mesos/src/docker/executor.cpp Ln 573-576:
const Option envPath = os::getenv("MESOS_LAUNCHER_DIR");
string path =
envPath.isSome() ? envPath.get()
: os::realpath(Path(argv[0]).dirname()).get();
The environmental variable MESOS_LAUNCHER_DIR is not passed and argv[0] is used
(which is the sandbox directory, not the launcher directory) for health check
directory.
> Mesos health check is invoked incorrectly when Mesos slave is within the
> docker container
> -
>
> Key: MESOS-3738
> URL: https://issues.apache.org/jira/browse/MESOS-3738
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.0:
> Client:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Server:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Host: Ubuntu 14.04
> Container: Debian 8.1 + Java-7
>Reporter: Yong Tang
>
> When Mesos slave is within the container, the COMMAND health check from
> Marathon is invoked incorrectly.
> Command to invoke the Mesos slave container:
> sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
> /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
> -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
> mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
> --executor_registration_timeout=5mins --docker_stop_timeout=10secs
> --launcher=posix
> Marathon JSON file:
> {
> "id": "ubuntu",
> "container":
> {
> "type": "DOCKER",
> "docker":
> {
> "image": "ubuntu",
> "network": "BRIDGE",
> "parameters": []
> }
> },
> "args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
> "uris": [],
> "healthChecks":
> [
> {
> "protocol": "COMMAND",
> "command": { "value": "echo Success" },
> "gracePeriodSeconds": 3000,
> "intervalSeconds": 5,
> "timeoutSeconds": 5,
> "maxConsecutiveFailures": 300
> }
> ],
> "instances": 1
> }
> STDOUT:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> Registered docker executor on b01e2e75afcb
> Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> 1
> Launching health check process:
> /tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f/mesos-health-check
> --executor=(1)@10.2.1.7:40695
> --health_check_json={"command":{"shell":true,"value":"docker exec
> mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f
> sh -c \" echo Success
> \""},"consecutive_failures":300,"delay_seconds":0.0,"grace_period_seconds":3000.0,"interval_seconds":5.0,"timeout_seconds":5.0}
> --task_id=ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> Health check process launched at pid: 94
> 1
> 1
> 1
> 1
> 1
> STDERR:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stderr
> I1014 23:15:58.12795056 exec.cpp:134] Version:
[jira] [Updated] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
[
https://issues.apache.org/jira/browse/MESOS-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yong Tang updated MESOS-3738:
-
Description:
When Mesos slave is within the container, the COMMAND health check from
Marathon is invoked incorrectly.
In such a scenario, the sandbox directory (instead of the launcher/health-check
directory) is used. This result in an error with the container.
Command to invoke the Mesos slave container:
sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
/usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
-v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
--executor_registration_timeout=5mins --docker_stop_timeout=10secs
--launcher=posix
Marathon JSON file:
{
"id": "ubuntu",
"container":
{
"type": "DOCKER",
"docker":
{
"image": "ubuntu",
"network": "BRIDGE",
"parameters": []
}
},
"args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
"uris": [],
"healthChecks":
[
{
"protocol": "COMMAND",
"command": { "value": "echo Success" },
"gracePeriodSeconds": 3000,
"intervalSeconds": 5,
"timeoutSeconds": 5,
"maxConsecutiveFailures": 300
}
],
"instances": 1
}
STDOUT:
root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
--container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--stop_timeout="10secs"
--container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--stop_timeout="10secs"
Registered docker executor on b01e2e75afcb
Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
1
Launching health check process:
/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f/mesos-health-check
--executor=(1)@10.2.1.7:40695
--health_check_json={"command":{"shell":true,"value":"docker exec
mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f
sh -c \" echo Success
\""},"consecutive_failures":300,"delay_seconds":0.0,"grace_period_seconds":3000.0,"interval_seconds":5.0,"timeout_seconds":5.0}
--task_id=ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
Health check process launched at pid: 94
1
1
1
1
1
STDERR:
root@cea2be47d64f:/mnt/mesos/sandbox# cat stderr
I1014 23:15:58.12795056 exec.cpp:134] Version: 0.25.0
I1014 23:15:58.13062762 exec.cpp:208] Executor registered on slave
e20f8959-cd9f-40ae-987d-809401309361-S0
WARNING: Your kernel does not support swap limit capabilities, memory limited
without swap.
ABORT:
(/tmp/mesos-build/mesos-repo/3rdparty/libprocess/src/subprocess.cpp:177):
Failed to os::execvpe in childMain: No such file or directory*** Aborted at
1444864558 (unix time) try "date -d @1444864558" if you are using GNU date ***
PC: @ 0x7fc8c5975107 (unknown)
*** SIGABRT (@0x5e) received by PID 94 (TID 0x7fc8bee5e700) from PID 94; stack
trace: ***
@ 0x7fc8c5cf88d0 (unknown)
@ 0x7fc8c5975107 (unknown)
@ 0x7fc8c59764e8 (unknown)
@ 0x419142 _Abort()
@ 0x41917c _Abort()
@ 0x7fc8c7745780 process::childMain()
@ 0x7fc8c7747a49 std::_Function_handler<>::_M_invoke()
@ 0x7fc8c774561c process::defaultClone()
@ 0x7fc8c7745f81 process::subprocess()
@ 0x43c58d
mesos::internal::docker::DockerExecutorProcess::launchHealthCheck()
@ 0x7fc8c771b424 process::ProcessManager::resume()
@ 0x7fc8c771b74f process::internal::schedule()
@ 0x7fc8c64d3970 (unknown)
@ 0x7fc8c5cf10a4 start_thread
@ 0x7fc8c5a2604d (unknown)
was:
When Mesos slave is within the container, the COMMAND health check from
Marathon is invoked incorrectly.
Command to invoke the Mesos slave container:
sudo docker run -d -v /sys:/sys -v
[jira] [Created] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
Yong Tang created MESOS-3738:
Summary: Mesos health check is invoked incorrectly when Mesos
slave is within the docker container
Key: MESOS-3738
URL: https://issues.apache.org/jira/browse/MESOS-3738
Project: Mesos
Issue Type: Bug
Components: docker
Affects Versions: 0.25.0
Environment: Docker 1.8.0:
Client:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: 0d03096
Built:Tue Aug 11 16:48:39 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: 0d03096
Built:Tue Aug 11 16:48:39 UTC 2015
OS/Arch: linux/amd64
Host: Ubuntu 14.04
Container: Debian 8.1 + Java-7
Reporter: Yong Tang
When Mesos slave is within the container, the COMMAND health check from
Marathon is invoked incorrectly.
Command to invoke the Mesos slave container:
sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
/usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
-v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
--executor_registration_timeout=5mins --docker_stop_timeout=10secs
--launcher=posix
Marathon JSON file:
{
"id": "ubuntu",
"container":
{
"type": "DOCKER",
"docker":
{
"image": "ubuntu",
"network": "BRIDGE",
"parameters": []
}
},
"args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
"uris": [],
"healthChecks":
[
{
"protocol": "COMMAND",
"command": { "value": "echo Success" },
"gracePeriodSeconds": 3000,
"intervalSeconds": 5,
"timeoutSeconds": 5,
"maxConsecutiveFailures": 300
}
],
"instances": 1
}
STDOUT:
root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
--container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--stop_timeout="10secs"
--container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
--initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
--mapped_directory="/mnt/mesos/sandbox" --quiet="false"
--sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
--stop_timeout="10secs"
Registered docker executor on b01e2e75afcb
Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
1
Launching health check process:
/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f/mesos-health-check
--executor=(1)@10.2.1.7:40695
--health_check_json={"command":{"shell":true,"value":"docker exec
mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f
sh -c \" echo Success
\""},"consecutive_failures":300,"delay_seconds":0.0,"grace_period_seconds":3000.0,"interval_seconds":5.0,"timeout_seconds":5.0}
--task_id=ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
Health check process launched at pid: 94
1
1
1
1
1
STDERR:
root@cea2be47d64f:/mnt/mesos/sandbox# cat stderr
I1014 23:15:58.12795056 exec.cpp:134] Version: 0.25.0
I1014 23:15:58.13062762 exec.cpp:208] Executor registered on slave
e20f8959-cd9f-40ae-987d-809401309361-S0
WARNING: Your kernel does not support swap limit capabilities, memory limited
without swap.
ABORT:
(/tmp/mesos-build/mesos-repo/3rdparty/libprocess/src/subprocess.cpp:177):
Failed to os::execvpe in childMain: No such file or directory*** Aborted at
1444864558 (unix time) try "date -d @1444864558" if you are using GNU date ***
PC: @ 0x7fc8c5975107 (unknown)
*** SIGABRT (@0x5e) received by PID 94 (TID 0x7fc8bee5e700) from PID 94; stack
trace: ***
@ 0x7fc8c5cf88d0 (unknown)
@ 0x7fc8c5975107 (unknown)
@ 0x7fc8c59764e8 (unknown)
@ 0x419142 _Abort()
@ 0x41917c _Abort()
@ 0x7fc8c7745780 process::childMain()
@ 0x7fc8c7747a49 std::_Function_handler<>::_M_invoke()
@ 0x7fc8c774561c process::defaultClone()
@ 0x7fc8c7745f81 process::subprocess()
@
