[jira] [Commented] (MESOS-9514) Reviewboard bot fails on verify-reviews.py.
[
https://issues.apache.org/jira/browse/MESOS-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763747#comment-16763747
]
Till Toenshoff commented on MESOS-9514:
---
{noformat}
commit 761e1ca400901dd623f1cb025e1d68da9472d49c
Author: Armand Grillet
Date: Fri Feb 8 17:17:11 2019 +0100
Refactored 'support/verify-reviews.py' to be closer to commit 7412179.
The goal of this commit is to make 'verify-reviews.py' as close as
possible to its last known working state (commit
74121798f24fca372180b8c4bc00b4df07d46240).
The diff between 'verify-reviews.py' at this commit and 7412179 is
available here: https://www.diffchecker.com/cmfaM83O All the new
features added since 7412179 have been added again and the code
has been made Python 3 compatible again.
The goal is to have a diff as minimal as possible with improvements
regarding logs so that we do not face CI issues anymore. Changes
have been made regarding how we run commands from the script so
that they are run from the repository instead of where the
script is being called.
Review: https://reviews.apache.org/r/69817/{noformat}
> Reviewboard bot fails on verify-reviews.py.
> ---
>
> Key: MESOS-9514
> URL: https://issues.apache.org/jira/browse/MESOS-9514
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Till Toenshoff
>Assignee: Armand Grillet
>Priority: Major
> Labels: integration
>
> Seeing this on our Azure based Mesos CI for review requests.
> {noformat}
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on dummy-slave-01 (dummy-slave) in workspace
> /home/jenkins/workspace/mesos-reviewbot
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url https://github.com/apache/mesos # timeout=10
> Pruning obsolete local branches
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from https://github.com/apache/mesos
> > git --version # timeout=10
> > git fetch --tags --progress https://github.com/apache/mesos
> +refs/heads/*:refs/remotes/origin/* --prune
> > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 3478e344fb77d931f6122980c6e94cd3913c441d
> (refs/remotes/origin/master)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f 3478e344fb77d931f6122980c6e94cd3913c441d
> Commit message: "Sent SIGKILL to I/O switchboard server as a safeguard."
> > git rev-list --no-walk 3478e344fb77d931f6122980c6e94cd3913c441d #
> timeout=10
> [mesos-reviewbot] $ /usr/bin/env bash /tmp/jenkins5023908134863801311.sh
> git rev-parse HEAD
> Traceback (most recent call last):
> File
> "/home/jenkins/workspace/mesos-reviewbot/mesos/support/verify-reviews.py",
> line 101, in
> HEAD = shell("git rev-parse HEAD")
> File
> "/home/jenkins/workspace/mesos-reviewbot/mesos/support/verify-reviews.py",
> line 97, in shell
> out = subprocess.check_output(command, stderr=subprocess.STDOUT,
> shell=True)
> File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
> **kwargs).stdout
> File "/usr/lib/python3.5/subprocess.py", line 708, in run
> output=stdout, stderr=stderr)
> subprocess.CalledProcessError: Command 'git rev-parse HEAD' returned non-zero
> exit status 128
> Build step 'Execute shell' marked build as failure
> Finished: FAILURE
> {noformat}
> This is happening pretty much exactly since we landed
> https://github.com/apache/mesos/commit/3badf7179992e61f30f5a79da9d481dd451c7c2f#diff-0bcbb572aad3fe39e0e5c3c8a8c3e515
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6632) ContainerLogger might leak FD if container launch fails.
[ https://issues.apache.org/jira/browse/MESOS-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Budnik updated MESOS-6632: - Comment: was deleted (was: [~gilbert] Could you please fill out Fix Version/s?) > ContainerLogger might leak FD if container launch fails. > > > Key: MESOS-6632 > URL: https://issues.apache.org/jira/browse/MESOS-6632 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 0.28.2, 1.0.1, 1.1.0 >Reporter: Jie Yu >Assignee: Andrei Budnik >Priority: Critical > > In MesosContainerizer, if logger->prepare() succeeds but its continuation > fails, the pipe fd allocated in the logger will get leaked. We cannot add a > destructor in ContainerLogger::SubprocessInfo to close the fd because > subprocess might close the OWNED fd. > A FD abstraction might help here. In other words, subprocess will no longer > be responsible for closing external FDs, instead, the FD destructor will be > doing so. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-6632) ContainerLogger might leak FD if container launch fails.
[ https://issues.apache.org/jira/browse/MESOS-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763730#comment-16763730 ] Andrei Budnik commented on MESOS-6632: -- [~gilbert] Could you please fill out Fix Version/s? > ContainerLogger might leak FD if container launch fails. > > > Key: MESOS-6632 > URL: https://issues.apache.org/jira/browse/MESOS-6632 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 0.28.2, 1.0.1, 1.1.0 >Reporter: Jie Yu >Assignee: Andrei Budnik >Priority: Critical > > In MesosContainerizer, if logger->prepare() succeeds but its continuation > fails, the pipe fd allocated in the logger will get leaked. We cannot add a > destructor in ContainerLogger::SubprocessInfo to close the fd because > subprocess might close the OWNED fd. > A FD abstraction might help here. In other words, subprocess will no longer > be responsible for closing external FDs, instead, the FD destructor will be > doing so. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-6632) ContainerLogger might leak FD if container launch fails.
[ https://issues.apache.org/jira/browse/MESOS-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Budnik reassigned MESOS-6632: Assignee: Andrei Budnik > ContainerLogger might leak FD if container launch fails. > > > Key: MESOS-6632 > URL: https://issues.apache.org/jira/browse/MESOS-6632 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 0.28.2, 1.0.1, 1.1.0 >Reporter: Jie Yu >Assignee: Andrei Budnik >Priority: Critical > > In MesosContainerizer, if logger->prepare() succeeds but its continuation > fails, the pipe fd allocated in the logger will get leaked. We cannot add a > destructor in ContainerLogger::SubprocessInfo to close the fd because > subprocess might close the OWNED fd. > A FD abstraction might help here. In other words, subprocess will no longer > be responsible for closing external FDs, instead, the FD destructor will be > doing so. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-6632) ContainerLogger might leak FD if container launch fails.
[ https://issues.apache.org/jira/browse/MESOS-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763727#comment-16763727 ] Andrei Budnik commented on MESOS-6632: -- https://reviews.apache.org/r/69684/ > ContainerLogger might leak FD if container launch fails. > > > Key: MESOS-6632 > URL: https://issues.apache.org/jira/browse/MESOS-6632 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 0.28.2, 1.0.1, 1.1.0 >Reporter: Jie Yu >Priority: Critical > > In MesosContainerizer, if logger->prepare() succeeds but its continuation > fails, the pipe fd allocated in the logger will get leaked. We cannot add a > destructor in ContainerLogger::SubprocessInfo to close the fd because > subprocess might close the OWNED fd. > A FD abstraction might help here. In other words, subprocess will no longer > be responsible for closing external FDs, instead, the FD destructor will be > doing so. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9562) Authorization for DESTROY and UNRESERVE is not symmetrical.
Alexander Rukletsov created MESOS-9562:
--
Summary: Authorization for DESTROY and UNRESERVE is not
symmetrical.
Key: MESOS-9562
URL: https://issues.apache.org/jira/browse/MESOS-9562
Project: Mesos
Issue Type: Improvement
Components: master, scheduler api
Affects Versions: 1.7.1
Reporter: Alexander Rukletsov
For [the {{UNRESERVE}}
case|https://github.com/apache/mesos/blob/5d3ed364c6d1307d88e6b950ae0eef423c426673/src/master/master.cpp#L3661-L3677],
if the principal was not set, {{.has_principal()}} will be {{false}}, hence we
will not call {{authorizations.push_back()}}, and hence we will not create an
authz request with this resource as an object. For [the {{DESTROY}}
case|https://github.com/apache/mesos/blob/5d3ed364c6d1307d88e6b950ae0eef423c426673/src/master/master.cpp#L3772-L3773],
if the principal was not set, a default value {{""}} for string will be used
and hence we will create an authz request with this resource as an object.
We definitely need to make the behaviour consistent. I'm not sure which
approach is correct.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
