[jira] [Updated] (MESOS-6913) AgentAPIStreamingTest.AttachInputToNestedContainerSession fails on Mac OS.
[
https://issues.apache.org/jira/browse/MESOS-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-6913:
--
Target Version/s: (was: 1.2.0)
> AgentAPIStreamingTest.AttachInputToNestedContainerSession fails on Mac OS.
> --
>
> Key: MESOS-6913
> URL: https://issues.apache.org/jira/browse/MESOS-6913
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Mac OS 10.11.6 with Apple clang-703.0.31
>Reporter: Alexander Rukletsov
>Assignee: Anand Mazumdar
>Priority: Critical
> Labels: mesosphere
>
> {noformat}
> [ RUN ]
> ContentType/AgentAPIStreamingTest.AttachInputToNestedContainerSession/0
> make[3]: *** [check-local] Illegal instruction: 4
> make[2]: *** [check-am] Error 2
> make[1]: *** [check] Error 2
> make: *** [check-recursive] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-6003) Add logging module for logging to an external program
[ https://issues.apache.org/jira/browse/MESOS-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874111#comment-15874111 ] Will Rouesnel commented on MESOS-6003: -- Huh I thought I had notified this thread - anyway - I've rebased the patchset for the changes that have been made to ContainerLogger interface, so this should be good to go again. > Add logging module for logging to an external program > - > > Key: MESOS-6003 > URL: https://issues.apache.org/jira/browse/MESOS-6003 > Project: Mesos > Issue Type: Improvement > Components: modules >Reporter: Will Rouesnel >Assignee: Will Rouesnel >Priority: Minor > > In the vein of the logrotate module for logging, there should be a similar > module which provides support for logging to an arbitrary log handling > program, with suitable task metadata provided by environment variables or > command line arguments. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MESOS-7068) Add OnTerminationPolicy handling to the default executor.
[
https://issues.apache.org/jira/browse/MESOS-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-7068:
--
Sprint: Mesosphere Sprint 51
Story Points: 3
https://reviews.apache.org/r/56835/
> Add OnTerminationPolicy handling to the default executor.
> -
>
> Key: MESOS-7068
> URL: https://issues.apache.org/jira/browse/MESOS-7068
> Project: Mesos
> Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
> Labels: mesosphere
>
> We should support handling {{OnTerminationPolicy}} specified in {{TaskInfo}}
> to the default executor. Currently, the default policy for the default
> executor is to kill the entire task group when a task in the task group
> fails. This would allow framework developers to specify a custom policy e.g.,
> keep the executor still alive when a back up task in the task group fails etc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-6988) WebUI redirect doesn't work with stats from /metrics/snapshot
[
https://issues.apache.org/jira/browse/MESOS-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874014#comment-15874014
]
haosdent commented on MESOS-6988:
-
The differences of {{/master/state}} and {{/metrics/snapshot}} is
{{/master/state}} is handled by {{Master}} whilte {{/metrics/snapshot}} is
handled by {{MetricsProcess}}. And we do redirection in {{Master}} while we
could not do redirection {{/metrics/snapshot}} (We may add a new endpoint under
master like {{/master/metrics_snapshot}} so it could support redirection).
So [~xujyan], you prefer to remove the fallback, right? I think we could do
that.
> WebUI redirect doesn't work with stats from /metrics/snapshot
> -
>
> Key: MESOS-6988
> URL: https://issues.apache.org/jira/browse/MESOS-6988
> Project: Mesos
> Issue Type: Bug
> Components: webui
>Affects Versions: 1.1.0
>Reporter: Yan Xu
>Assignee: haosdent
>
> The issue described in MESOS-6446 is still not fixed in 1.1.0. (Especially
> for non-leading masters)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7143) ABORT checks its preconditions incorrectly and incompletely
[
https://issues.apache.org/jira/browse/MESOS-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873919#comment-15873919
]
James Peach commented on MESOS-7143:
Similarly the {{ABORT}} macro is optimistic. It lets you pass multiple
arguments but {{_Abort}} only takes 1 message:
{code}
#define ABORT(...) _Abort(_ABORT_PREFIX, __VA_ARGS__)
{code}
For _Abort itself, consider annotating the arguments to be non-null and
removing the checks. It's not cool to abort without an actionable message.
> ABORT checks its preconditions incorrectly and incompletely
> ---
>
> Key: MESOS-7143
> URL: https://issues.apache.org/jira/browse/MESOS-7143
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Affects Versions: 0.23.0
>Reporter: Benjamin Bannier
>Priority: Minor
> Labels: coverity, tech-debt
>
> Currently, stout's {{ABORT}} (which is mapped to {{_Abort}}) checks it
> precondition incompletely and incorrectly.
> Its current control flow is roughly
> {code}
> void _Abort(const char* prefix, const char* message)
> {
> size_t prefix_len = strlen(prefix);
> size_t message_len = strlen(message);
>
> // Async-safe write.
>while(::write(2, prefix, prefix_len) == -1 && errno == EINTR);
>while(message != nullptr &&
> ::write(2, message, message_len) == -1 && errno == EINTR);
> }
> {code}
> We here check the precondition {{message != nullptr}} after we already have
> called {{strlen(message)}}; calling {{strlen}} on a {{nullptr}} already
> triggers undefined behavior.
> Similarly, we never guard against a {{prefix}} which is {{nullptr}}, but
> unconditionally call {{strlen}} on it.
> It seems it should be possible to assert that neither {{prefix}} nor
> {{message}} are {{nullptr}} before any use.
> This was diagnosed by coverity as CID-1400833, and has been present in all
> releases since 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
