[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056888#comment-16056888
]
Mao Geng commented on MESOS-7692:
-
[~tillt] The framework always use {{-C DOCKER}}, however somehow mesos launched
a container like this:
{code}
I0620 20:29:03.457880 70274 containerizer.cpp:1524] Launching
'mesos-containerizer' with flags '--help="false"
--launch_info="{"clone_namespaces":[131072],"command":{"arguments":["mesos-executor","--launcher_dir=\/usr\/libexec\/mesos"],"shell":false,"value":"\/usr\/libexec\/mesos\/mesos-executor"},"environment":{"variables":[{"name":"LIBPROCESS_PORT","type":"VALUE","value":"0"},{"name":"MESOS_AGENT_ENDPOINT","type":"VALUE","value":"10.1.160.40:5051"},{"name":"MESOS_CHECKPOINT","type":"VALUE","value":"0"},{"name":"MESOS_DIRECTORY","type":"VALUE","value":"\/mnt\/mesos\/slaves\/f2bcc63d-e887-4e25-b2c0-3772dfb40fb0-S8\/frameworks\/609ef166-7000-4c8d-a6ed-909e4d504eaa-0049\/executors\/10\/runs\/c7e77d1e-e411-4703-805f-10bbf9a0eaf8"},{"name":"MESOS_EXECUTOR_ID","type":"VALUE","value":"10"},{"name":"MESOS_EXECUTOR_SHUTDOWN_GRACE_PERIOD","type":"VALUE","value":"5secs"},{"name":"MESOS_FRAMEWORK_ID","type":"VALUE","value":"609ef166-7000-4c8d-a6ed-909e4d504eaa-0049"},{"name":"MESOS_HTTP_COMMAND_EXECUTOR","type":"VALUE","value":"0"},{"name":"MESOS_NATIVE_JAVA_LIBRARY","type":"VALUE","value":"\/usr\/lib\/libmesos-1.3.0.so"},{"name":"MESOS_NATIVE_LIBRARY","type":"VALUE","value":"\/usr\/lib\/libmesos-1.3.0.so"},{"name":"MESOS_SLAVE_ID","type":"VALUE","value":"f2bcc63d-e887-4e25-b2c0-3772dfb40fb0-S8"},{"name":"MESOS_SLAVE_PID","type":"VALUE","value":"slave(1)@10.1.160.40:5051"},{"name":"MESOS_SANDBOX","type":"VALUE","value":"\/mnt\/mesos\/slaves\/f2bcc63d-e887-4e25-b2c0-3772dfb40fb0-S8\/frameworks\/609ef166-7000-4c8d-a6ed-909e4d504eaa-0049\/executors\/10\/runs\/c7e77d1e-e411-4703-805f-10bbf9a0eaf8"},{"name":"PYTHONPATH","type":"VALUE","value":"\/:\/usr\/lib\/python2.7:\/usr\/lib\/python2.7\/plat-x86_64-linux-gnu:\/usr\/lib\/python2.7\/lib-tk:\/usr\/lib\/python2.7\/lib-old:\/usr\/lib\/python2.7\/lib-dynload:\/usr\/local\/lib\/python2.7\/dist-packages:\/usr\/lib\/python2.7\/dist-packages"}]},"pre_exec_commands":[{"arguments":["mesos-containerizer","mount","--help=false","--operation=make-rslave","--path=\/"],"shell":false,"value":"\/usr\/libexec\/mesos\/mesos-containerizer"}],"user":"root","working_directory":"\/mnt\/mesos\/slaves\/f2bcc63d-e887-4e25-b2c0-3772dfb40fb0-S8\/frameworks\/609ef166-7000-4c8d-a6ed-909e4d504eaa-0049\/executors\/10\/runs\/c7e77d1e-e411-4703-805f-10bbf9a0eaf8"}"
--pipe_read="29" --pipe_write="30"
--runtime_directory="/var/run/mesos/containers/c7e77d1e-e411-4703-805f-10bbf9a0eaf8"
--unshare_namespace_mnt="false"'
{code}
Same framework with {{-C DOCKER}} option can launch docker container correctly
with Mesos 1.2.0
> Default environment variables defined in docker image are not available in
> mesos containerizer
> --
>
> Key: MESOS-7692
> URL: https://issues.apache.org/jira/browse/MESOS-7692
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Mao Geng
>Assignee: Till Toenshoff
>Priority: Blocker
> Fix For: 1.3.1
>
>
> Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined
> by ENV statements in dockerfile are not available in mesos containerizer any
> more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image,
> JAVA_HOME of java:8 image, etc.
> The env vars are available in mesos containerizer in 1.2.0. Looks like a
> regression to me, isn't it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056859#comment-16056859
]
Till Toenshoff commented on MESOS-7692:
---
[~gengmao] so {{-C DOCKER}} is ignored and that framework always uses {{-C
MESOS}} instead?
> Default environment variables defined in docker image are not available in
> mesos containerizer
> --
>
> Key: MESOS-7692
> URL: https://issues.apache.org/jira/browse/MESOS-7692
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Mao Geng
>Assignee: Till Toenshoff
>Priority: Blocker
> Fix For: 1.3.1
>
>
> Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined
> by ENV statements in dockerfile are not available in mesos containerizer any
> more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image,
> JAVA_HOME of java:8 image, etc.
> The env vars are available in mesos containerizer in 1.2.0. Looks like a
> regression to me, isn't it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056834#comment-16056834 ] Till Toenshoff commented on MESOS-7692: --- Review for regression test: https://reviews.apache.org/r/60258 > Default environment variables defined in docker image are not available in > mesos containerizer > -- > > Key: MESOS-7692 > URL: https://issues.apache.org/jira/browse/MESOS-7692 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 1.3.0 >Reporter: Mao Geng >Assignee: Till Toenshoff >Priority: Blocker > Fix For: 1.3.1 > > > Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined > by ENV statements in dockerfile are not available in mesos containerizer any > more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image, > JAVA_HOME of java:8 image, etc. > The env vars are available in mesos containerizer in 1.2.0. Looks like a > regression to me, isn't it? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7670) Add tests for reservation refinement.
[
https://issues.apache.org/jira/browse/MESOS-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056773#comment-16056773
]
Michael Park commented on MESOS-7670:
-
{noformat}
commit 69187c749f47bbebaaf1122de66d8e905d9a7c34
Author: Michael Park
Date: Tue Jun 20 16:16:37 2017 -0700
Added missing `RESERVATION_REFINEMENT` capability to examples and tests.
This is a follow-up to https://reviews.apache.org/r/60073/.
We missed a few places in root tests and examples which aren't part of
the test suite.
Review: https://reviews.apache.org/r/60254
{noformat}
> Add tests for reservation refinement.
> -
>
> Key: MESOS-7670
> URL: https://issues.apache.org/jira/browse/MESOS-7670
> Project: Mesos
> Issue Type: Task
>Reporter: Benjamin Mahler
>Assignee: Michael Park
>
> We should be sure to capture:
> * Frameworks refining and unrefining reservations.
> * Operators doing the same.
> * v0 endpoint (e.g. /state) backwards compatibility w.r.t. formatting.
> * Spoofed upgrade testing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7670) Add tests for reservation refinement.
[ https://issues.apache.org/jira/browse/MESOS-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056739#comment-16056739 ] Michael Park commented on MESOS-7670: - https://reviews.apache.org/r/60254/ > Add tests for reservation refinement. > - > > Key: MESOS-7670 > URL: https://issues.apache.org/jira/browse/MESOS-7670 > Project: Mesos > Issue Type: Task >Reporter: Benjamin Mahler >Assignee: Michael Park > > We should be sure to capture: > * Frameworks refining and unrefining reservations. > * Operators doing the same. > * v0 endpoint (e.g. /state) backwards compatibility w.r.t. formatting. > * Spoofed upgrade testing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056740#comment-16056740
]
Mao Geng commented on MESOS-7692:
-
[~tillt] I found another issue today, not sure if it is same root cause.
Tfmesos, the framework based on HTTP Scheduler API to run tensorflow in docker
on mesos, couldn't submit tasks in Docker containerizer any more. Previously I
could run https://github.com/douban/tfmesos/blob/master/script/tfrun#L17 with
{{-C DOCKER}}, which would launch tasks by docker containerizer, however, on
mesos 1.3.0-2.0.3 the tasks were launched by mesos containerizer even with same
option and code.
Could you please help troubleshoot? Should I open a new ticket for that?
> Default environment variables defined in docker image are not available in
> mesos containerizer
> --
>
> Key: MESOS-7692
> URL: https://issues.apache.org/jira/browse/MESOS-7692
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Mao Geng
>Assignee: Till Toenshoff
>Priority: Blocker
> Fix For: 1.3.1
>
>
> Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined
> by ENV statements in dockerfile are not available in mesos containerizer any
> more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image,
> JAVA_HOME of java:8 image, etc.
> The env vars are available in mesos containerizer in 1.2.0. Looks like a
> regression to me, isn't it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-7679) V1 Operator API update for reservation refinement.
[ https://issues.apache.org/jira/browse/MESOS-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Park reassigned MESOS-7679: --- Resolution: Fixed Assignee: Michael Park Fix Version/s: 1.4.0 Target Version/s: 1.4.0 > V1 Operator API update for reservation refinement. > -- > > Key: MESOS-7679 > URL: https://issues.apache.org/jira/browse/MESOS-7679 > Project: Mesos > Issue Type: Bug >Reporter: Michael Park >Assignee: Michael Park > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-7665) V0 Operator API update for reservation refinement.
[ https://issues.apache.org/jira/browse/MESOS-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Park reassigned MESOS-7665: --- Resolution: Fixed Assignee: Michael Park Fix Version/s: 1.4.0 Target Version/s: 1.4.0 > V0 Operator API update for reservation refinement. > -- > > Key: MESOS-7665 > URL: https://issues.apache.org/jira/browse/MESOS-7665 > Project: Mesos > Issue Type: Task >Reporter: Benjamin Mahler >Assignee: Michael Park > Fix For: 1.4.0 > > > In order to preserve backwards compatibility, the v0 endpoints (e.g. /state) > should expose the old format using `Resource.role` and `Resource.reservation` > if the resources do not contain a refined reservation. > If the resource contains a refined reservation, then we need to ensure the v0 > endpoints reflect that in the JSON. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7679) V1 Operator API update for reservation refinement.
[
https://issues.apache.org/jira/browse/MESOS-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056735#comment-16056735
]
Michael Park commented on MESOS-7679:
-
{noformat}
commit 663cf58c29b8b03e1733395791fe958e7fb6b298
Author: Michael Park
Date: Sun Jun 18 23:32:52 2017 -0700
Converted the resources to the "endpoint" format for V1 endpoints.
Review: https://reviews.apache.org/r/60187
{noformat}
> V1 Operator API update for reservation refinement.
> --
>
> Key: MESOS-7679
> URL: https://issues.apache.org/jira/browse/MESOS-7679
> Project: Mesos
> Issue Type: Bug
>Reporter: Michael Park
> Fix For: 1.4.0
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7665) V0 Operator API update for reservation refinement.
[
https://issues.apache.org/jira/browse/MESOS-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056734#comment-16056734
]
Michael Park commented on MESOS-7665:
-
{noformat}
commit fd3e9e9f16f6659d3eb88da02b7d02b2d49bd729
Author: Michael Park mcyp...@gmail.com
Date: Tue Jun 13 01:40:43 2017 -0700
Converted the resources to the "endpoint" format for V0 endpoints.
Review: https://reviews.apache.org/r/60041
{noformat}
> V0 Operator API update for reservation refinement.
> --
>
> Key: MESOS-7665
> URL: https://issues.apache.org/jira/browse/MESOS-7665
> Project: Mesos
> Issue Type: Task
>Reporter: Benjamin Mahler
>
> In order to preserve backwards compatibility, the v0 endpoints (e.g. /state)
> should expose the old format using `Resource.role` and `Resource.reservation`
> if the resources do not contain a refined reservation.
> If the resource contains a refined reservation, then we need to ensure the v0
> endpoints reflect that in the JSON.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7665) V0 Operator API update for reservation refinement.
[
https://issues.apache.org/jira/browse/MESOS-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056734#comment-16056734
]
Michael Park edited comment on MESOS-7665 at 6/21/17 12:45 AM:
---
{noformat}
commit fd3e9e9f16f6659d3eb88da02b7d02b2d49bd729
Author: Michael Park
Date: Tue Jun 13 01:40:43 2017 -0700
Converted the resources to the "endpoint" format for V0 endpoints.
Review: https://reviews.apache.org/r/60041
{noformat}
was (Author: mcypark):
{noformat}
commit fd3e9e9f16f6659d3eb88da02b7d02b2d49bd729
Author: Michael Park mcyp...@gmail.com
Date: Tue Jun 13 01:40:43 2017 -0700
Converted the resources to the "endpoint" format for V0 endpoints.
Review: https://reviews.apache.org/r/60041
{noformat}
> V0 Operator API update for reservation refinement.
> --
>
> Key: MESOS-7665
> URL: https://issues.apache.org/jira/browse/MESOS-7665
> Project: Mesos
> Issue Type: Task
>Reporter: Benjamin Mahler
>
> In order to preserve backwards compatibility, the v0 endpoints (e.g. /state)
> should expose the old format using `Resource.role` and `Resource.reservation`
> if the resources do not contain a refined reservation.
> If the resource contains a refined reservation, then we need to ensure the v0
> endpoints reflect that in the JSON.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7700) Prevent reserve/create operations with refined reservations on non-capable agents.
Michael Park created MESOS-7700: --- Summary: Prevent reserve/create operations with refined reservations on non-capable agents. Key: MESOS-7700 URL: https://issues.apache.org/jira/browse/MESOS-7700 Project: Mesos Issue Type: Bug Components: master Reporter: Michael Park Assignee: Michael Park Reserve / create operations with refined reservation should be rejected if they are being performed on non-capable agents. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056672#comment-16056672
]
Till Toenshoff commented on MESOS-7692:
---
[~jieyu] yup, I am tackling that.
The scenario however is even broader and unfortunately still not covered by our
tests...
What that bug did was that it was serializing environment data in the wrong
format -- jsonified hashmap instead of jsonified Environment proto. This
serializing happens when being forwarded as a task specific (not executor
inherited) environment towards the command executor {{task_environment}}. As a
result no task specific environment variables were forwarded. Such task
specific environment could come e.g. from a runtime isolator (docker). So the
reported issue is just one manifestation of a bad bug in our very unfortunately
complex data flow towards the command executor.
> Default environment variables defined in docker image are not available in
> mesos containerizer
> --
>
> Key: MESOS-7692
> URL: https://issues.apache.org/jira/browse/MESOS-7692
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Mao Geng
>Assignee: Till Toenshoff
>Priority: Blocker
> Fix For: 1.3.1
>
>
> Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined
> by ENV statements in dockerfile are not available in mesos containerizer any
> more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image,
> JAVA_HOME of java:8 image, etc.
> The env vars are available in mesos containerizer in 1.2.0. Looks like a
> regression to me, isn't it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056611#comment-16056611 ] Jie Yu edited comment on MESOS-7692 at 6/20/17 10:56 PM: - [~tillt] and [~gilbert], can we add a regression test for this? A simple regression test using some test docker image that has environment variable set. Make sure the environment variable is set in the task. was (Author: jieyu): [~tillt] and [~gilbert], can we add a regression test for this? > Default environment variables defined in docker image are not available in > mesos containerizer > -- > > Key: MESOS-7692 > URL: https://issues.apache.org/jira/browse/MESOS-7692 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 1.3.0 >Reporter: Mao Geng >Assignee: Till Toenshoff >Priority: Blocker > Fix For: 1.3.1 > > > Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined > by ENV statements in dockerfile are not available in mesos containerizer any > more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image, > JAVA_HOME of java:8 image, etc. > The env vars are available in mesos containerizer in 1.2.0. Looks like a > regression to me, isn't it? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[ https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056611#comment-16056611 ] Jie Yu commented on MESOS-7692: --- [~tillt] and [~gilbert], can we add a regression test for this? > Default environment variables defined in docker image are not available in > mesos containerizer > -- > > Key: MESOS-7692 > URL: https://issues.apache.org/jira/browse/MESOS-7692 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 1.3.0 >Reporter: Mao Geng >Assignee: Till Toenshoff >Priority: Blocker > Fix For: 1.3.1 > > > Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined > by ENV statements in dockerfile are not available in mesos containerizer any > more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image, > JAVA_HOME of java:8 image, etc. > The env vars are available in mesos containerizer in 1.2.0. Looks like a > regression to me, isn't it? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7692) Default environment variables defined in docker image are not available in mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056575#comment-16056575
]
Till Toenshoff commented on MESOS-7692:
---
We missed a release cut for a bugfix - the issue got introduced by 1973ab5
which landed shortly before 1.3.0 got cut -- the fix then landed only in 1.4.0
wip (master).
Now fixed in 1.3.x by
{noformat}
commit 24c211386132e2b89e5ad81f480e687eeb3c8c80
Author: Till Toenshoff
Date: Tue Jun 20 21:22:36 2017 +0200
Fixed task_environment serializing in containerizer.
Review: https://reviews.apache.org/r/59140/
{noformat}
> Default environment variables defined in docker image are not available in
> mesos containerizer
> --
>
> Key: MESOS-7692
> URL: https://issues.apache.org/jira/browse/MESOS-7692
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Mao Geng
>Assignee: Till Toenshoff
>Priority: Blocker
>
> Found an unexpected change in 1.3.0-2.0.3 - the environment variables defined
> by ENV statements in dockerfile are not available in mesos containerizer any
> more. For example LD_LIBRARY_PATH of tensorflow/tensorflow:latest-gpu image,
> JAVA_HOME of java:8 image, etc.
> The env vars are available in mesos containerizer in 1.2.0. Looks like a
> regression to me, isn't it?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7699) "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable freshly released)
[
https://issues.apache.org/jira/browse/MESOS-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-7699:
Labels: autotools (was: )
> "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable
> freshly released)
> ---
>
> Key: MESOS-7699
> URL: https://issues.apache.org/jira/browse/MESOS-7699
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.2.0
>Reporter: Adam Cecile
> Labels: autotools
>
> Hi,
> It seems the issue comes from a workaround added a while ago:
> https://reviews.apache.org/r/40326/
> https://reviews.apache.org/r/40327/
> When building with external libraries it turns out creating build commands
> line with -isystem /usr/include which is clearly stated as being wrong,
> according to GCC guys:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
> I'll do some testing by reverting all -isystem to -I and I'll let it know if
> it gets built.
> Regards, Adam.
> {noformat}
> configure:21642: result: no
> configure:21642: checking glog/logging.h presence
> configure:21642: g++ -E -I/usr/include -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -Wdate-time -D_FORTIFY_SOURCE=2 -isystem /usr/include
> -I/usr/include conftest.cpp
> In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
> from /usr/include/c++/6/bits/basic_string.h:5417,
> from /usr/include/c++/6/string:52,
> from /usr/include/c++/6/bits/locale_classes.h:40,
> from /usr/include/c++/6/bits/ios_base.h:41,
> from /usr/include/c++/6/ios:42,
> from /usr/include/c++/6/ostream:38,
> from /usr/include/glog/logging.h:43,
> from conftest.cpp:32:
> /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or
> directory
> #include_next
> ^
> compilation terminated.
> configure:21642: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "mesos"
> | #define PACKAGE_TARNAME "mesos"
> | #define PACKAGE_VERSION "1.2.0"
> | #define PACKAGE_STRING "mesos 1.2.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define PACKAGE "mesos"
> | #define VERSION "1.2.0"
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_DLFCN_H 1
> | #define LT_OBJDIR ".libs/"
> | #define HAVE_CXX11 1
> | #define HAVE_PTHREAD_PRIO_INHERIT 1
> | #define HAVE_PTHREAD 1
> | #define HAVE_LIBZ 1
> | #define HAVE_FTS_H 1
> | #define HAVE_APR_POOLS_H 1
> | #define HAVE_LIBAPR_1 1
> | #define HAVE_BOOST_VERSION_HPP 1
> | #define HAVE_LIBCURL 1
> | /* end confdefs.h. */
> | #include
> configure:21642: result: no
> configure:21642: checking for glog/logging.h
> configure:21642: result: no
> configure:21674: error: cannot find glog
> ---
> You have requested the use of a non-bundled glog but no suitable
> glog could be found.
> You may want specify the location of glog by providing a prefix
> path via --with-glog=DIR, or check that the path you provided is
> correct if you're already doing this.
> ---
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7699) "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable freshly released)
[
https://issues.apache.org/jira/browse/MESOS-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056345#comment-16056345
]
Benjamin Bannier commented on MESOS-7699:
-
That Boost issue looks unrelated to the originally reported issue here.
Depending on what version of Mesos you are building, I suspect you are picking
up an incompatible Boost version from {{/usr}}, i.e., the issue fix in
MESOS-7581 (we currently bundle boost-1.53.0 and expect a compatible version if
we find it). Feel free to comment over there if you see a connection, or create
a new issue if not.
> "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable
> freshly released)
> ---
>
> Key: MESOS-7699
> URL: https://issues.apache.org/jira/browse/MESOS-7699
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.2.0
>Reporter: Adam Cecile
>
> Hi,
> It seems the issue comes from a workaround added a while ago:
> https://reviews.apache.org/r/40326/
> https://reviews.apache.org/r/40327/
> When building with external libraries it turns out creating build commands
> line with -isystem /usr/include which is clearly stated as being wrong,
> according to GCC guys:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
> I'll do some testing by reverting all -isystem to -I and I'll let it know if
> it gets built.
> Regards, Adam.
> {noformat}
> configure:21642: result: no
> configure:21642: checking glog/logging.h presence
> configure:21642: g++ -E -I/usr/include -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -Wdate-time -D_FORTIFY_SOURCE=2 -isystem /usr/include
> -I/usr/include conftest.cpp
> In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
> from /usr/include/c++/6/bits/basic_string.h:5417,
> from /usr/include/c++/6/string:52,
> from /usr/include/c++/6/bits/locale_classes.h:40,
> from /usr/include/c++/6/bits/ios_base.h:41,
> from /usr/include/c++/6/ios:42,
> from /usr/include/c++/6/ostream:38,
> from /usr/include/glog/logging.h:43,
> from conftest.cpp:32:
> /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or
> directory
> #include_next
> ^
> compilation terminated.
> configure:21642: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "mesos"
> | #define PACKAGE_TARNAME "mesos"
> | #define PACKAGE_VERSION "1.2.0"
> | #define PACKAGE_STRING "mesos 1.2.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define PACKAGE "mesos"
> | #define VERSION "1.2.0"
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_DLFCN_H 1
> | #define LT_OBJDIR ".libs/"
> | #define HAVE_CXX11 1
> | #define HAVE_PTHREAD_PRIO_INHERIT 1
> | #define HAVE_PTHREAD 1
> | #define HAVE_LIBZ 1
> | #define HAVE_FTS_H 1
> | #define HAVE_APR_POOLS_H 1
> | #define HAVE_LIBAPR_1 1
> | #define HAVE_BOOST_VERSION_HPP 1
> | #define HAVE_LIBCURL 1
> | /* end confdefs.h. */
> | #include
> configure:21642: result: no
> configure:21642: checking for glog/logging.h
> configure:21642: result: no
> configure:21674: error: cannot find glog
> ---
> You have requested the use of a non-bundled glog but no suitable
> glog could be found.
> You may want specify the location of glog by providing a prefix
> path via --with-glog=DIR, or check that the path you provided is
> correct if you're already doing this.
> ---
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7699) "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable freshly released)
[
https://issues.apache.org/jira/browse/MESOS-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056336#comment-16056336
]
Adam Cecile commented on MESOS-7699:
Yep, I guess that could help...
Sadly, there's other issue with GCC 6 with bundled stout and libprocess.
Here's a first batch:
{noformat}
./../stout/include/stout/json.hpp:261:30: error: no matching function for call
to 'boost::variant::variant(const
std::__cxx11::basic_string&)'
: internal::Variant(value) {}
^
In file included from /usr/include/boost/variant.hpp:17:0,
from ./../stout/include/stout/json.hpp:35,
from ./include/process/http.hpp:38,
from ./include/process/event.hpp:19,
from ./include/process/process.hpp:24,
from ./include/process/dispatch.hpp:20,
from ./include/process/deferred.hpp:18,
from ./include/process/defer.hpp:19,
from src/process.cpp:66:
{noformat}
{noformat}
/usr/include/boost/variant/variant.hpp:1782:5: error: no type named 'type' in
'struct boost::enable_if, boost::mpl::not_ >, boost::mpl::not_ > >,
boost::detail::variant::is_variant_constructible_from&, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_end> > > > > > >,
mpl_::bool_ >, void>'
{noformat}
{noformat}
/usr/include/boost/variant/variant.hpp:1768:5: error: no type named 'type' in
'struct
boost::enable_if >, boost::mpl::not_ > >,
boost::detail::variant::is_variant_constructible_from&, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_end> > > > > > >,
mpl_::bool_, mpl_::bool_ >, void>'
./../stout/include/stout/json.hpp: In instantiation of
'JSON::Value::Value(const T&, typename
boost::disable_if::type) [with T =
std::__cxx11::basic_string; typename
boost::disable_if::type = int]':
{noformat}
{noformat}
/usr/include/boost/variant/variant.hpp:1758:5: error: no type named 'type' in
'struct
boost::enable_if > >,
boost::detail::variant::is_variant_constructible_from&, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_item,
boost::recursive_wrapper, boost::mpl::l_end> > > > > > >,
mpl_::bool_, mpl_::bool_, mpl_::bool_ >, void>'
In file included from /usr/include/boost/variant.hpp:17:0,
from ./../stout/include/stout/json.hpp:35,
from ./include/process/http.hpp:38,
from ./include/process/event.hpp:19,
from ./include/process/process.hpp:24,
from ./include/process/dispatch.hpp:20,
from ./include/process/deferred.hpp:18,
from ./include/process/defer.hpp:19,
from src/process.cpp:66:
{noformat}
Sadly I got no C++ kill and it looks looks like chinese to me. But I'm there,
available for testing if you need some feedbacks...
Regards, Adam.
> "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable
> freshly released)
>
[jira] [Commented] (MESOS-7699) "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable freshly released)
[
https://issues.apache.org/jira/browse/MESOS-7699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056325#comment-16056325
]
Benjamin Bannier commented on MESOS-7699:
-
Linked two issues where we introduced such code.
It appears a possible fix could be to just not add {{/usr/include}} to the
search path -- I suspect it would be in the default search path anyway.
> "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable
> freshly released)
> ---
>
> Key: MESOS-7699
> URL: https://issues.apache.org/jira/browse/MESOS-7699
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.2.0
>Reporter: Adam Cecile
>
> Hi,
> It seems the issue comes from a workaround added a while ago:
> https://reviews.apache.org/r/40326/
> https://reviews.apache.org/r/40327/
> When building with external libraries it turns out creating build commands
> line with -isystem /usr/include which is clearly stated as being wrong,
> according to GCC guys:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
> I'll do some testing by reverting all -isystem to -I and I'll let it know if
> it gets built.
> Regards, Adam.
> {noformat}
> configure:21642: result: no
> configure:21642: checking glog/logging.h presence
> configure:21642: g++ -E -I/usr/include -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -Wdate-time -D_FORTIFY_SOURCE=2 -isystem /usr/include
> -I/usr/include conftest.cpp
> In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
> from /usr/include/c++/6/bits/basic_string.h:5417,
> from /usr/include/c++/6/string:52,
> from /usr/include/c++/6/bits/locale_classes.h:40,
> from /usr/include/c++/6/bits/ios_base.h:41,
> from /usr/include/c++/6/ios:42,
> from /usr/include/c++/6/ostream:38,
> from /usr/include/glog/logging.h:43,
> from conftest.cpp:32:
> /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or
> directory
> #include_next
> ^
> compilation terminated.
> configure:21642: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "mesos"
> | #define PACKAGE_TARNAME "mesos"
> | #define PACKAGE_VERSION "1.2.0"
> | #define PACKAGE_STRING "mesos 1.2.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define PACKAGE "mesos"
> | #define VERSION "1.2.0"
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_DLFCN_H 1
> | #define LT_OBJDIR ".libs/"
> | #define HAVE_CXX11 1
> | #define HAVE_PTHREAD_PRIO_INHERIT 1
> | #define HAVE_PTHREAD 1
> | #define HAVE_LIBZ 1
> | #define HAVE_FTS_H 1
> | #define HAVE_APR_POOLS_H 1
> | #define HAVE_LIBAPR_1 1
> | #define HAVE_BOOST_VERSION_HPP 1
> | #define HAVE_LIBCURL 1
> | /* end confdefs.h. */
> | #include
> configure:21642: result: no
> configure:21642: checking for glog/logging.h
> configure:21642: result: no
> configure:21674: error: cannot find glog
> ---
> You have requested the use of a non-bundled glog but no suitable
> glog could be found.
> You may want specify the location of glog by providing a prefix
> path via --with-glog=DIR, or check that the path you provided is
> correct if you're already doing this.
> ---
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7699) "stdlib.h: No such file or directory" when building with GCC 6 (Debian stable freshly released)
Adam Cecile created MESOS-7699:
--
Summary: "stdlib.h: No such file or directory" when building with
GCC 6 (Debian stable freshly released)
Key: MESOS-7699
URL: https://issues.apache.org/jira/browse/MESOS-7699
Project: Mesos
Issue Type: Bug
Components: build
Affects Versions: 1.2.0
Reporter: Adam Cecile
Hi,
It seems the issue comes from a workaround added a while ago:
https://reviews.apache.org/r/40326/
https://reviews.apache.org/r/40327/
When building with external libraries it turns out creating build commands line
with -isystem /usr/include which is clearly stated as being wrong, according to
GCC guys:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
I'll do some testing by reverting all -isystem to -I and I'll let it know if it
gets built.
Regards, Adam.
{noformat}
configure:21642: result: no
configure:21642: checking glog/logging.h presence
configure:21642: g++ -E -I/usr/include -I/usr/include/apr-1
-I/usr/include/apr-1.0 -Wdate-time -D_FORTIFY_SOURCE=2 -isystem /usr/include
-I/usr/include conftest.cpp
In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
from /usr/include/c++/6/bits/basic_string.h:5417,
from /usr/include/c++/6/string:52,
from /usr/include/c++/6/bits/locale_classes.h:40,
from /usr/include/c++/6/bits/ios_base.h:41,
from /usr/include/c++/6/ios:42,
from /usr/include/c++/6/ostream:38,
from /usr/include/glog/logging.h:43,
from conftest.cpp:32:
/usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or
directory
#include_next
^
compilation terminated.
configure:21642: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "mesos"
| #define PACKAGE_TARNAME "mesos"
| #define PACKAGE_VERSION "1.2.0"
| #define PACKAGE_STRING "mesos 1.2.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define PACKAGE "mesos"
| #define VERSION "1.2.0"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_CXX11 1
| #define HAVE_PTHREAD_PRIO_INHERIT 1
| #define HAVE_PTHREAD 1
| #define HAVE_LIBZ 1
| #define HAVE_FTS_H 1
| #define HAVE_APR_POOLS_H 1
| #define HAVE_LIBAPR_1 1
| #define HAVE_BOOST_VERSION_HPP 1
| #define HAVE_LIBCURL 1
| /* end confdefs.h. */
| #include
configure:21642: result: no
configure:21642: checking for glog/logging.h
configure:21642: result: no
configure:21674: error: cannot find glog
---
You have requested the use of a non-bundled glog but no suitable
glog could be found.
You may want specify the location of glog by providing a prefix
path via --with-glog=DIR, or check that the path you provided is
correct if you're already doing this.
---
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7694) Discarding process::loop doesn't stop the loop
[
https://issues.apache.org/jira/browse/MESOS-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056018#comment-16056018
]
Yan Xu commented on MESOS-7694:
---
/cc [~benjaminhindman] [~bmahler]
> Discarding process::loop doesn't stop the loop
> --
>
> Key: MESOS-7694
> URL: https://issues.apache.org/jira/browse/MESOS-7694
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Yan Xu
>
> When a loop's returned future is discarded, the loop would attempt to stop
> itself from progressing by propagating the discard to the future that
> {{iteration}} or {{body}} are blocked on. However for cases such as the run
> is dispatched and pending, or {{iteration}} or {{body}} are not blocked at
> all, discarding the loop doesn't stop it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7698) Libprocess doesn't handle IP changes
Ilya Pronin created MESOS-7698:
--
Summary: Libprocess doesn't handle IP changes
Key: MESOS-7698
URL: https://issues.apache.org/jira/browse/MESOS-7698
Project: Mesos
Issue Type: Bug
Components: libprocess
Affects Versions: 1.2.0
Reporter: Ilya Pronin
If a host IP address changes libprocess will never learn about it and will
continue to send messages "from" the old IP.
This will cause weird situations. E.g. an agent will indefinitely try to
reregister with a master pretending that it can be reached by an old IP. The
master will send {{SlaveReregisteredMessage}} to the wrong host (potentially a
different agent), using an IP from the {{User-Agent: libprocess/*}} header.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7697) Mesos scheduler v1 HTTP API may generate 404 errors for temporary conditions
[
https://issues.apache.org/jira/browse/MESOS-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-7697:
--
Component/s: libprocess
> Mesos scheduler v1 HTTP API may generate 404 errors for temporary conditions
>
>
> Key: MESOS-7697
> URL: https://issues.apache.org/jira/browse/MESOS-7697
> Project: Mesos
> Issue Type: Bug
> Components: HTTP API, libprocess
>Reporter: James DeFelice
> Labels: mesosphere
>
> Returning a 404 error for a condition that's a known temporary condition is
> confusing from a client's perspective. A client wants to know how to recover
> from various error conditions. A 404 error condition should be distinct from
> a "server is not yet ready, but will be shortly" condition (which should
> probably be reported as a 503 "unavailable" error).
> https://github.com/apache/mesos/blob/72752fc6deb8ebcbfbd5448dc599ef3774339d31/src/scheduler/scheduler.cpp#L593
> {code}
> if (response->code == process::http::Status::NOT_FOUND) {
> // This could happen if the master libprocess process has not yet set up
> // HTTP routes.
> LOG(WARNING) << "Received '" << response->status << "' ("
><< response->body << ") for " << call.type();
> return;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7697) Mesos scheduler v1 HTTP API may generate 404 errors for temporary conditions
[
https://issues.apache.org/jira/browse/MESOS-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-7697:
--
Component/s: HTTP API
> Mesos scheduler v1 HTTP API may generate 404 errors for temporary conditions
>
>
> Key: MESOS-7697
> URL: https://issues.apache.org/jira/browse/MESOS-7697
> Project: Mesos
> Issue Type: Bug
> Components: HTTP API, libprocess
>Reporter: James DeFelice
> Labels: mesosphere
>
> Returning a 404 error for a condition that's a known temporary condition is
> confusing from a client's perspective. A client wants to know how to recover
> from various error conditions. A 404 error condition should be distinct from
> a "server is not yet ready, but will be shortly" condition (which should
> probably be reported as a 503 "unavailable" error).
> https://github.com/apache/mesos/blob/72752fc6deb8ebcbfbd5448dc599ef3774339d31/src/scheduler/scheduler.cpp#L593
> {code}
> if (response->code == process::http::Status::NOT_FOUND) {
> // This could happen if the master libprocess process has not yet set up
> // HTTP routes.
> LOG(WARNING) << "Received '" << response->status << "' ("
><< response->body << ") for " << call.type();
> return;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7697) Mesos scheduler v1 HTTP API may generate 404 errors for temporary conditions
James DeFelice created MESOS-7697:
-
Summary: Mesos scheduler v1 HTTP API may generate 404 errors for
temporary conditions
Key: MESOS-7697
URL: https://issues.apache.org/jira/browse/MESOS-7697
Project: Mesos
Issue Type: Bug
Reporter: James DeFelice
Returning a 404 error for a condition that's a known temporary condition is
confusing from a client's perspective. A client wants to know how to recover
from various error conditions. A 404 error condition should be distinct from a
"server is not yet ready, but will be shortly" condition (which should probably
be reported as a 503 "unavailable" error).
https://github.com/apache/mesos/blob/72752fc6deb8ebcbfbd5448dc599ef3774339d31/src/scheduler/scheduler.cpp#L593
{code}
if (response->code == process::http::Status::NOT_FOUND) {
// This could happen if the master libprocess process has not yet set up
// HTTP routes.
LOG(WARNING) << "Received '" << response->status << "' ("
<< response->body << ") for " << call.type();
return;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7696) Update resource provider design in the master
Jan Schlicht created MESOS-7696: --- Summary: Update resource provider design in the master Key: MESOS-7696 URL: https://issues.apache.org/jira/browse/MESOS-7696 Project: Mesos Issue Type: Task Components: master Reporter: Jan Schlicht Assignee: Jan Schlicht Some discussion around how to use the allocator result in changes to how local resource providers and external resource providers should be handled in the master. The current approach needs to be updated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7693) DEBUG container does not inherit env variable properly for command tasks.
[
https://issues.apache.org/jira/browse/MESOS-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055622#comment-16055622
]
Alexander Rukletsov commented on MESOS-7693:
Does not this happen because of MESOS-7692, i.e. the parent container does not
have the env var set and hence it is not inherited, [~jieyu]?
> DEBUG container does not inherit env variable properly for command tasks.
> -
>
> Key: MESOS-7693
> URL: https://issues.apache.org/jira/browse/MESOS-7693
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jie Yu
>Assignee: Alexander Rukletsov
>
> I can repo the issue:
> {code}
> sudo /home/vagrant/workspace/dist/mesos-1.4.0/bin/mesos-execute
> --master=172.28.128.3:5050 --name=java8 --docker_image=java:8
> --command="sleep 1000"
> I0618 17:42:21.410598 3356 scheduler.cpp:184] Version: 1.4.0
> I0618 17:42:21.413465 3356 scheduler.cpp:470] New master detected at
> master@172.28.128.3:5050
> Subscribed with ID cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006
> Submitted task 'java8' to agent 'cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0'
> Received status update TASK_RUNNING for task 'java8'
> source: SOURCE_EXECUTOR
> Jies-MacBook-Pro:script jie$ ./dcos task
> NAME HOST USER STATE ID
> java8 172.28.128.3 rootRjava8
> Jies-MacBook-Pro:script jie$ ./dcos task exec -t -i java8 bash
> root@vagrant-ubuntu-trusty-64:/mnt/mesos/sandbox# env
> LIBPROCESS_IP=172.28.128.3
> MESOS_AGENT_ENDPOINT=172.28.128.3:5051
> MESOS_DIRECTORY=/tmp/mesos/slave/slaves/cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0/frameworks/cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006/executors/java8/runs/1b06c661-20f3-460a-8cfd-475dc3e60aa3
> MESOS_EXECUTOR_ID=java8
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/mnt/mesos/sandbox
> MESOS_EXECUTOR_SHUTDOWN_GRACE_PERIOD=5secs
> MESOS_NATIVE_JAVA_LIBRARY=/home/vagrant/workspace/dist/mesos-1.4.0/lib/libmesos-1.4.0.so
> MESOS_NATIVE_LIBRARY=/home/vagrant/workspace/dist/mesos-1.4.0/lib/libmesos-1.4.0.so
> MESOS_HTTP_COMMAND_EXECUTOR=0
> MESOS_SLAVE_PID=slave(1)@172.28.128.3:5051
> MESOS_FRAMEWORK_ID=cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006
> MESOS_CHECKPOINT=0
> SHLVL=1
> LIBPROCESS_PORT=0
> MESOS_SLAVE_ID=cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0
> MESOS_SANDBOX=/mnt/mesos/sandbox
> _=/usr/bin/env
> {code}
> As you can see, environment variables like JAVA_HOME defined in the docker
> image are not in the debug container.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7693) DEBUG container does not inherit env variable properly for command tasks.
[
https://issues.apache.org/jira/browse/MESOS-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055622#comment-16055622
]
Alexander Rukletsov edited comment on MESOS-7693 at 6/20/17 11:46 AM:
--
Isn't this happening because of MESOS-7692, i.e. the parent container does not
have the env var set and hence it is not inherited, [~jieyu]?
was (Author: alexr):
Does not this happen because of MESOS-7692, i.e. the parent container does not
have the env var set and hence it is not inherited, [~jieyu]?
> DEBUG container does not inherit env variable properly for command tasks.
> -
>
> Key: MESOS-7693
> URL: https://issues.apache.org/jira/browse/MESOS-7693
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jie Yu
>Assignee: Alexander Rukletsov
>
> I can repo the issue:
> {code}
> sudo /home/vagrant/workspace/dist/mesos-1.4.0/bin/mesos-execute
> --master=172.28.128.3:5050 --name=java8 --docker_image=java:8
> --command="sleep 1000"
> I0618 17:42:21.410598 3356 scheduler.cpp:184] Version: 1.4.0
> I0618 17:42:21.413465 3356 scheduler.cpp:470] New master detected at
> master@172.28.128.3:5050
> Subscribed with ID cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006
> Submitted task 'java8' to agent 'cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0'
> Received status update TASK_RUNNING for task 'java8'
> source: SOURCE_EXECUTOR
> Jies-MacBook-Pro:script jie$ ./dcos task
> NAME HOST USER STATE ID
> java8 172.28.128.3 rootRjava8
> Jies-MacBook-Pro:script jie$ ./dcos task exec -t -i java8 bash
> root@vagrant-ubuntu-trusty-64:/mnt/mesos/sandbox# env
> LIBPROCESS_IP=172.28.128.3
> MESOS_AGENT_ENDPOINT=172.28.128.3:5051
> MESOS_DIRECTORY=/tmp/mesos/slave/slaves/cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0/frameworks/cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006/executors/java8/runs/1b06c661-20f3-460a-8cfd-475dc3e60aa3
> MESOS_EXECUTOR_ID=java8
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/mnt/mesos/sandbox
> MESOS_EXECUTOR_SHUTDOWN_GRACE_PERIOD=5secs
> MESOS_NATIVE_JAVA_LIBRARY=/home/vagrant/workspace/dist/mesos-1.4.0/lib/libmesos-1.4.0.so
> MESOS_NATIVE_LIBRARY=/home/vagrant/workspace/dist/mesos-1.4.0/lib/libmesos-1.4.0.so
> MESOS_HTTP_COMMAND_EXECUTOR=0
> MESOS_SLAVE_PID=slave(1)@172.28.128.3:5051
> MESOS_FRAMEWORK_ID=cacf5c08-cbbc-401a-a84d-2cfc4edc6519-0006
> MESOS_CHECKPOINT=0
> SHLVL=1
> LIBPROCESS_PORT=0
> MESOS_SLAVE_ID=cacf5c08-cbbc-401a-a84d-2cfc4edc6519-S0
> MESOS_SANDBOX=/mnt/mesos/sandbox
> _=/usr/bin/env
> {code}
> As you can see, environment variables like JAVA_HOME defined in the docker
> image are not in the debug container.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-6390) Ensure Python support scripts are linted
[
https://issues.apache.org/jira/browse/MESOS-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055518#comment-16055518
]
Armand Grillet commented on MESOS-6390:
---
I've landed some review requests concerning this ticket today, assigning myself
now.
> Ensure Python support scripts are linted
>
>
> Key: MESOS-6390
> URL: https://issues.apache.org/jira/browse/MESOS-6390
> Project: Mesos
> Issue Type: Improvement
>Reporter: Benjamin Bannier
>Assignee: Manuwela Kanade
> Labels: newbie, python
>
> Currently {{support/mesos-style.py}} does not lint files under {{support/}}.
> This is mostly due to the fact that these scripts are too inconsistent
> style-wise that they wouldn't even pass the linter now.
> We should clean up all Python scripts under {{support/}} so they pass the
> Python linter, and activate that directory in the linter for future
> additions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7670) Add tests for reservation refinement.
[
https://issues.apache.org/jira/browse/MESOS-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055491#comment-16055491
]
Michael Park commented on MESOS-7670:
-
{noformat}
commit 9036c31873954c59d8e03076796acf2e578c10a8
Author: Michael Park
Date: Tue Jun 20 01:10:57 2017 -0700
Updated authorization tests [20/20].
Review: https://reviews.apache.org/r/60074/
{noformat}
{noformat}
commit c55f44fe1e19fbe850e62250883fcb7aac0d8057
Author: Michael Park
Date: Tue Jun 20 01:10:27 2017 -0700
Adjusted tests to the new resource format [19/20].
Review: https://reviews.apache.org/r/60072/
{noformat}
{noformat}
commit ded150a97c6e80af6a7df440c313e85cf2a25fe3
Author: Michael Park
Date: Tue Jun 20 01:10:15 2017 -0700
Added `RESERVATION_REFINEMENT` capability to tests [18/20].
Review: https://reviews.apache.org/r/60073/
{noformat}
> Add tests for reservation refinement.
> -
>
> Key: MESOS-7670
> URL: https://issues.apache.org/jira/browse/MESOS-7670
> Project: Mesos
> Issue Type: Task
>Reporter: Benjamin Mahler
>Assignee: Michael Park
>
> We should be sure to capture:
> * Frameworks refining and unrefining reservations.
> * Operators doing the same.
> * v0 endpoint (e.g. /state) backwards compatibility w.r.t. formatting.
> * Spoofed upgrade testing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-7674) Update the generic Protobuf to JSON facility to not output deprecated fields
[
https://issues.apache.org/jira/browse/MESOS-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park reassigned MESOS-7674:
---
Resolution: Fixed
Assignee: Michael Park
Fix Version/s: 1.4.0
{noformat}
commit 6749cfd58ef9d76636ebb0d5c0ad92891dd82e34
Author: Michael Park
Date: Tue Jun 20 01:09:29 2017 -0700
Removed `modelProtobufJSON` and replaced with `JSON::Protobuf` [16/20].
Review: https://reviews.apache.org/r/60223/
{noformat}
{noformat}
commit b71fe0313173bb72490ec4b63b384297ded6b1d7
Author: Michael Park
Date: Tue Jun 20 01:09:19 2017 -0700
Marked `Resource.role` as deprecated [15/20].
Review: https://reviews.apache.org/r/60222/
{noformat}
{noformat}
commit 9374529209fa6b7d67530b3b44ef36dc2d0fe896
Author: Michael Park
Date: Tue Jun 20 01:06:31 2017 -0700
Changed the semantics of `JSON::protobuf` for deprecated fields [14/20].
Updated `JSON::protobuf` to not emit a __deprecated__ optional field
with a default value if it's not explicitly set. The specific issue
we're solving here is that the round-trip of Protobuf to JSON and
back does not work with the current behavior. For example,
the `Resource` object in the "post-reservation-refinement" format does
not have the `Resource.role` field. During the Protobuf -> JSON
conversion, the `"role"` field is set to `"*"` since it is an optional
field with a default value. When such a JSON object is parsed back in
as a Protobuf message, the `Resource` object is in an invalid state.
In order to facilitate this at least in the short term, this patch
changes the generic Protobuf -> JSON logic to not output unset fields
if they are marked deprecated.
Review: https://reviews.apache.org/r/60207/
{noformat}
> Update the generic Protobuf to JSON facility to not output deprecated fields
>
>
> Key: MESOS-7674
> URL: https://issues.apache.org/jira/browse/MESOS-7674
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Michael Park
>Assignee: Michael Park
> Fix For: 1.4.0
>
>
> The current generic Protobuf to JSON conversion logic in
> {{stout/protobuf.hpp}} prints out fields even if they are deprecated. It
> would be useful to not print deprecated fields so that the user is not
> confused as to why they're seeing it.
> In the context of reservation refinement, the {{Resource.role}} field is
> printed even if it's not set, because it's an optional field with a default
> value. For now, we've added a terrible hack to avoid having to be printed. It
> would be much better to update the generic Protobuf to JSON code to not print
> deprecated fields, and we can remove this hack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7666) Update the agent to use the new resource format
[
https://issues.apache.org/jira/browse/MESOS-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055485#comment-16055485
]
Michael Park commented on MESOS-7666:
-
{noformat}
commit 0d5792d8ff62bd6415ad605c215fce3a7f9da229
Author: Michael Park
Date: Mon Jun 19 14:30:19 2017 -0700
Adjusted the agent to the new resources format [11/20].
The agent uses `convertResourceFormat` to convert the in-bound
resources to the "post-reseration-refinement" format, and
the out-bound resources are converted back to "pre-" or
"endpoint" format as necessary.
Review: https://reviews.apache.org/r/60070
{noformat}
{noformat}
commit 78ea693723cb8f12944b079d442c474ea13666db
Author: Michael Park
Date: Mon Jun 19 13:14:18 2017 -0700
Added the agent `RESERVATION_REFINEMENT` capability [13/20].
Review: https://reviews.apache.org/r/60190
{noformat}
> Update the agent to use the new resource format
> ---
>
> Key: MESOS-7666
> URL: https://issues.apache.org/jira/browse/MESOS-7666
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Reporter: Michael Park
>Assignee: Michael Park
> Fix For: 1.4.0
>
>
> With reservation refinement, the `Resource.reservations` field is used to
> express the notion of reservations rather than the old `Resource.role`,
> `Resource.reservation` pair. The agent code needs to be updated to reflect
> this change.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7667) Update the master to use the new resource format.
[
https://issues.apache.org/jira/browse/MESOS-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055483#comment-16055483
]
Michael Park commented on MESOS-7667:
-
{noformat}
commit 2398ef71b08ff94e3c0e93683e238fbd9ea65aed
Author: Michael Park mp...@apache.org
Date: Wed Jun 14 23:54:38 2017 -0700
Adjusted (UN)RESERVE operations to handle reservation refinement [8/20].
The logic for applying RESERVE operations now needs to ensure that the
pre-reserved resources are being refined. In other words, the RESERVE
operation should be "pushing" a single reservation to the stack. Note
that we only support "pushing" a single reservation at a time.
For UNRESERVE, the operation should "pop" the last reservation off the
stack. We only support "popping" a single reservation at a time.
This patch also replaces all of the uses of `flatten()` to
`toUnreserved()` and also removes `flatten()` entirely. We also replace
the uses of `flatten(role, reservation)` except in tests. We'll remove
this version in later patch.
Review: https://reviews.apache.org/r/60021
{noformat}
{noformat}
commit 3e8311e53db9af73ee9219480b6ec9b475578048
Author: Michael Park
Date: Sun Jun 18 21:12:07 2017 -0700
Adjusted the master validation to the new resource format [9/20].
Review: https://reviews.apache.org/r/60185
{noformat}
{noformat}
commit 0322de5971a72fa0750f07703994be206967158d
Author: Michael Park mp...@apache.org
Date: Sat Jun 17 15:38:58 2017 -0700
Adjusted the master to the new resources format [10/20].
The master uses `convertResourceFormat` to convert the in-bound
resources to the "post-reservation-refinement" format, and
the out-bound resources are converted back the "pre-", or
"endpoint" format as necessary.
Review: https://reviews.apache.org/r/60069
{noformat}
> Update the master to use the new resource format.
> -
>
> Key: MESOS-7667
> URL: https://issues.apache.org/jira/browse/MESOS-7667
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Michael Park
>Assignee: Michael Park
> Fix For: 1.4.0
>
>
> With reservation refinement, the `Resource.reservations` field is used to
> express the notion of reservations rather than the old `Resource.role`,
> `Resource.reservation` pair. The master code needs to be updated to reflect
> this change.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7655) Reservation Refinement: Update the resources logic.
[
https://issues.apache.org/jira/browse/MESOS-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055480#comment-16055480
]
Michael Park commented on MESOS-7655:
-
{noformat}
commit 7877b46f74730b61daf5179121139b40df26c2a6
Author: Michael Park
Date: Sun Jun 18 21:15:14 2017 -0700
Introduced a utility function `Resources::reservationRole` [7/20].
Review: https://reviews.apache.org/r/60015
{noformat}
{noformat}
commit 76b0f4ed82a51ab9eec3dc2b0d1542c8b29d1ab6
Author: Michael Park
Date: Tue Jun 13 01:40:21 2017 -0700
Resources: Adjusted `parse` to produce new resource format [6/20].
Review: https://reviews.apache.org/r/60040
{noformat}
{noformat}
commit 0bae26707645f515317b3860b22df822dd85e718
Author: Michael Park
Date: Sun Jun 18 22:04:29 2017 -0700
Resources: Adjusted the utilities to the new resource format [5/20].
Review: https://reviews.apache.org/r/60017
{noformat}
{noformat}
commit 9ac264bf533b96629dbb742e42c93b537a88ef6e
Author: Michael Park
Date: Sun Jun 18 22:05:10 2017 -0700
Resources: Adjusted `operator<<` to the new resource format [4/20].
Review: https://reviews.apache.org/r/60184
{noformat}
{noformat}
commit 2d78e5aec75bdd2b6115d9a822a93e8b5fa70283
Author: Michael Park
Date: Thu May 25 17:20:37 2017 -0700
Resources: Adjusted the comparators to new resource format [3/20].
Review: https://reviews.apache.org/r/60016
{noformat}
{noformat}
commit 1e220035de84245694ccf92b1fd2307aff2d3342
Author: Michael Park
Date: Sun Jun 18 22:03:25 2017 -0700
Resources: Adjusted the predicates to the new resource format [2/20].
The predicate resource functions have the same preconditions as
the `Resources`, in that they require the given `Resource` object
to be validated, and in the "post-reservation-refinement" format.
As such, the corresponding preconditions have been added as a `CHECK`,
and the functions have been updated to inspect the correct fields.
Review: https://reviews.apache.org/r/60182
{noformat}
{noformat}
commit db2babf9829edbd20124c04b93910ce370d62f08
Author: Michael Park
Date: Sun Jun 18 21:55:12 2017 -0700
Resources: Updated the comment to mention the resource format [1/20].
With reservation refinement, `Resources` always stores `Resource`
objects that are validated, and in the "post-reservation-refinement"
format. Added this precondition to the top of `Resources` declaration.
Review: https://reviews.apache.org/r/60181
{noformat}
> Reservation Refinement: Update the resources logic.
> ---
>
> Key: MESOS-7655
> URL: https://issues.apache.org/jira/browse/MESOS-7655
> Project: Mesos
> Issue Type: Bug
>Reporter: Michael Park
>Assignee: Michael Park
> Fix For: 1.4.0
>
>
> With reservation refinement, there is a new framework capability called
> {{RESERVATION_REFINEMENT}}. The framework is required to use the
> {{Resource.reservations}} field to express reservations if the capability is
> set, otherwise it is required to use the {{Resource.role}} and
> {{Resource.reservation}} fields.
> After the validation, we transform the resources from the old format to the
> new format and deal with the new format internally.
> This allows us to only deal with the old format at the validation phase, and
> update the code to only consider the new format for all other
> Resources-related functions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-6743) Docker executor hangs forever if `docker stop` fails.
[
https://issues.apache.org/jira/browse/MESOS-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-6743:
---
Affects Version/s: 1.2.1
1.3.0
Priority: Critical (was: Major)
> Docker executor hangs forever if `docker stop` fails.
> -
>
> Key: MESOS-6743
> URL: https://issues.apache.org/jira/browse/MESOS-6743
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 1.0.1, 1.1.0, 1.2.1, 1.3.0
>Reporter: Alexander Rukletsov
>Priority: Critical
> Labels: mesosphere
>
> If {{docker stop}} finishes with an error status, the executor should catch
> this and react instead of indefinitely waiting for {{reaped}} to return.
> An interesting question is _how_ to react. Here are possible solutions.
> 1. Retry {{docker stop}}. In this case it is unclear how many times to retry
> and what to do if {{docker stop}} continues to fail.
> 2. Unmark task as {{killed}}. This will allow frameworks to retry the kill.
> However, in this case it is unclear what status updates we should send:
> {{TASK_KILLING}} for every kill retry? an extra update when we failed to kill
> a task? or set a specific reason in {{TASK_KILLING}}?
> 3. Clean up and exit. In this case we should make sure the task container is
> killed or notify the framework and the operator that the container may still
> be running.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7666) Update the agent to use the new resource format
[ https://issues.apache.org/jira/browse/MESOS-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048985#comment-16048985 ] Michael Park edited comment on MESOS-7666 at 6/20/17 9:21 AM: -- https://reviews.apache.org/r/60070/ https://reviews.apache.org/r/60190/ was (Author: mcypark): https://reviews.apache.org/r/60070/ > Update the agent to use the new resource format > --- > > Key: MESOS-7666 > URL: https://issues.apache.org/jira/browse/MESOS-7666 > Project: Mesos > Issue Type: Bug > Components: agent >Reporter: Michael Park >Assignee: Michael Park > > With reservation refinement, the `Resource.reservations` field is used to > express the notion of reservations rather than the old `Resource.role`, > `Resource.reservation` pair. The agent code needs to be updated to reflect > this change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7674) Update the generic Protobuf to JSON facility to not output deprecated fields
[
https://issues.apache.org/jira/browse/MESOS-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055423#comment-16055423
]
Michael Park commented on MESOS-7674:
-
https://reviews.apache.org/r/60207/
https://reviews.apache.org/r/60222/
https://reviews.apache.org/r/60223/
> Update the generic Protobuf to JSON facility to not output deprecated fields
>
>
> Key: MESOS-7674
> URL: https://issues.apache.org/jira/browse/MESOS-7674
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Michael Park
>
> The current generic Protobuf to JSON conversion logic in
> {{stout/protobuf.hpp}} prints out fields even if they are deprecated. It
> would be useful to not print deprecated fields so that the user is not
> confused as to why they're seeing it.
> In the context of reservation refinement, the {{Resource.role}} field is
> printed even if it's not set, because it's an optional field with a default
> value. For now, we've added a terrible hack to avoid having to be printed. It
> would be much better to update the generic Protobuf to JSON code to not print
> deprecated fields, and we can remove this hack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7667) Update the master to use the new resource format.
[ https://issues.apache.org/jira/browse/MESOS-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055422#comment-16055422 ] Michael Park commented on MESOS-7667: - https://reviews.apache.org/r/60021/ https://reviews.apache.org/r/60185/ > Update the master to use the new resource format. > - > > Key: MESOS-7667 > URL: https://issues.apache.org/jira/browse/MESOS-7667 > Project: Mesos > Issue Type: Bug > Components: master >Reporter: Michael Park >Assignee: Michael Park > > With reservation refinement, the `Resource.reservations` field is used to > express the notion of reservations rather than the old `Resource.role`, > `Resource.reservation` pair. The master code needs to be updated to reflect > this change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7655) Reservation Refinement: Update the resources logic.
[
https://issues.apache.org/jira/browse/MESOS-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053489#comment-16053489
]
Michael Park edited comment on MESOS-7655 at 6/20/17 9:13 AM:
--
https://reviews.apache.org/r/60181/
https://reviews.apache.org/r/60182/
https://reviews.apache.org/r/60016/
https://reviews.apache.org/r/60184/
https://reviews.apache.org/r/60017/
https://reviews.apache.org/r/60040/
https://reviews.apache.org/r/60015/
was (Author: mcypark):
https://reviews.apache.org/r/60181/
https://reviews.apache.org/r/60182/
https://reviews.apache.org/r/60184/
https://reviews.apache.org/r/60016/
https://reviews.apache.org/r/60017/
https://reviews.apache.org/r/60040/
https://reviews.apache.org/r/60015/
> Reservation Refinement: Update the resources logic.
> ---
>
> Key: MESOS-7655
> URL: https://issues.apache.org/jira/browse/MESOS-7655
> Project: Mesos
> Issue Type: Bug
>Reporter: Michael Park
>Assignee: Michael Park
>
> With reservation refinement, there is a new framework capability called
> {{RESERVATION_REFINEMENT}}. The framework is required to use the
> {{Resource.reservations}} field to express reservations if the capability is
> set, otherwise it is required to use the {{Resource.role}} and
> {{Resource.reservation}} fields.
> After the validation, we transform the resources from the old format to the
> new format and deal with the new format internally.
> This allows us to only deal with the old format at the validation phase, and
> update the code to only consider the new format for all other
> Resources-related functions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7380) mesos-ps reports NameError: global name 'threading' is not defined
[ https://issues.apache.org/jira/browse/MESOS-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055378#comment-16055378 ] Haiwei Zhou commented on MESOS-7380: Forgot to publish. > mesos-ps reports NameError: global name 'threading' is not defined > -- > > Key: MESOS-7380 > URL: https://issues.apache.org/jira/browse/MESOS-7380 > Project: Mesos > Issue Type: Bug > Components: cli >Affects Versions: 1.2.0 >Reporter: Haiwei Zhou > > > mesos ps --master mesos-master:5050 > USERFRAMEWORKTASK SLAVE MEMTIME > CPU (allocated)Traceback (most recent call last): > File "/usr/bin/mesos-ps", line 242, in > main() > File "/usr/bin/mesos-ps", line 208, in main > for slave in slaves) > File "/usr/bin/mesos-ps", line 208, in > for slave in slaves) > File "/usr/lib/python2.7/site-packages/mesos/futures.py", line 175, in > submit > thread = threading.Thread(target=run) > NameError: global name 'threading' is not defined -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-4992) sandbox uri does not work outisde mesos http server
[ https://issues.apache.org/jira/browse/MESOS-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055300#comment-16055300 ] haosdent commented on MESOS-4992: - [~skonto] Sorry for the delay. Have fixed. > sandbox uri does not work outisde mesos http server > --- > > Key: MESOS-4992 > URL: https://issues.apache.org/jira/browse/MESOS-4992 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.27.1 >Reporter: Stavros Kontopoulos >Assignee: haosdent > Labels: mesosphere > Fix For: 1.4.0 > > > The SandBox uri of a framework does not work if i just copy paste it to the > browser. > For example the following sandbox uri: > http://172.17.0.1:5050/#/slaves/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0/frameworks/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-0009/executors/driver-20160321155016-0001/browse > should redirect to: > http://172.17.0.1:5050/#/slaves/50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0/browse?path=%2Ftmp%2Fmesos%2Fslaves%2F50f87c73-79ef-4f2a-95f0-b2b4062b2de6-S0%2Fframeworks%2F50f87c73-79ef-4f2a-95f0-b2b4062b2de6-0009%2Fexecutors%2Fdriver-20160321155016-0001%2Fruns%2F60533483-31fb-4353-987d-f3393911cc80 > yet it fails with the message: > "Failed to find slaves. > Navigate to the slave's sandbox via the Mesos UI." > and redirects to: > http://172.17.0.1:5050/#/ > It is an issue for me because im working on expanding the mesos spark ui with > sandbox uri, The other option is to get the slave info and parse the json > file there and get executor paths not so straightforward or elegant though. > Moreover i dont see the runs/container_id in the Mesos Proto Api. I guess > this is hidden info, this is the needed piece of info to re-write the uri > without redirection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
