[jira] [Commented] (MESOS-3394) Change glog download target for Windows when pull req is moved upstream
[ https://issues.apache.org/jira/browse/MESOS-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081714#comment-16081714 ] Andrew Schwartzmeyer commented on MESOS-3394: - We should wait for the next release of Glog, which includes full Windows support (stack tracing, symbol resolution, and signal handling). > Change glog download target for Windows when pull req is moved upstream > --- > > Key: MESOS-3394 > URL: https://issues.apache.org/jira/browse/MESOS-3394 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Andrew Schwartzmeyer > Labels: build, cmake, mesosphere > > To build on Windows, we have to build glog on Windows. But, glog doesn't > build on Windows, so we had to submit a patch to the project. So, to build on > Windows, we download the patched version directly from the pull request that > was sent to the glog repository on GitHub. > When these patches move upstream, we need to change this to point at the > "real" glog release instead of the pull request. > (For details see the `CMakeLists.txt` in `3rdparty/libprocess/3rdparty`.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MESOS-7778) Hide per-platform subprocess headers.
James Peach created MESOS-7778:
--
Summary: Hide per-platform subprocess headers.
Key: MESOS-7778
URL: https://issues.apache.org/jira/browse/MESOS-7778
Project: Mesos
Issue Type: Bug
Components: libprocess
Reporter: James Peach
Assignee: James Peach
{{libprocess}} exposes a number of implementation details via
{{posix/subprocess.hpp}} and {{windows/subprocess.hpp}}. We should hide these
details by making these headers internal to {{libprocess}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7777) Agent failed to recover due to mount namespace leakage in Docker 1.12/1.13
Chun-Hung Hsiao created MESOS-: -- Summary: Agent failed to recover due to mount namespace leakage in Docker 1.12/1.13 Key: MESOS- URL: https://issues.apache.org/jira/browse/MESOS- Project: Mesos Issue Type: Bug Components: docker Reporter: Chun-Hung Hsiao Assignee: Chun-Hung Hsiao Fix For: 1.4.0 Docker changed its default mount propagation to "shared" since 1.12 to enable persistent volume plugins. However, Docker has a known issue (https://github.com/moby/moby/issues/25718) that it sometimes leaks its mount namespace to other processes, which could make Mesos agents fail to remove Docker containers during recovery. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-3394) Change glog download target for Windows when pull req is moved upstream
[ https://issues.apache.org/jira/browse/MESOS-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Wu updated MESOS-3394: - Shepherd: Joseph Wu (was: Joris Van Remoortere) > Change glog download target for Windows when pull req is moved upstream > --- > > Key: MESOS-3394 > URL: https://issues.apache.org/jira/browse/MESOS-3394 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Andrew Schwartzmeyer > Labels: build, cmake, mesosphere > > To build on Windows, we have to build glog on Windows. But, glog doesn't > build on Windows, so we had to submit a patch to the project. So, to build on > Windows, we download the patched version directly from the pull request that > was sent to the glog repository on GitHub. > When these patches move upstream, we need to change this to point at the > "real" glog release instead of the pull request. > (For details see the `CMakeLists.txt` in `3rdparty/libprocess/3rdparty`.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-6101) Add event for Framwork added to master operator API
[ https://issues.apache.org/jira/browse/MESOS-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn updated MESOS-6101: - Shepherd: Greg Mann (was: Anand Mazumdar) > Add event for Framwork added to master operator API > --- > > Key: MESOS-6101 > URL: https://issues.apache.org/jira/browse/MESOS-6101 > Project: Mesos > Issue Type: Task >Reporter: Zhitao Li >Assignee: Quinn > > Consider the following case: > 1) a subscriber connects to master; > 2) a new scheduler registered as a new framework; > 3) a task is launched from this framework. > In this sequence, subscriber does not have a way to know the FrameworkInfo > belonging to the FrameworkId. > We should support an event (e.g. when framework info in master is > added/changed). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7548) net::hostname takes 5 seconds on Windows
[ https://issues.apache.org/jira/browse/MESOS-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081332#comment-16081332 ] Joseph Wu commented on MESOS-7548: -- Related review: https://reviews.apache.org/r/60291/ > net::hostname takes 5 seconds on Windows > > > Key: MESOS-7548 > URL: https://issues.apache.org/jira/browse/MESOS-7548 > Project: Mesos > Issue Type: Bug > Environment: Windows 10 >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer > Labels: stout, windows > > We've determined that when starting the master in a unit test, instead of > milliseconds, it takes upwards of five seconds to start. However, providing a > set of flags where `hostname` is specified, it takes less than a second. > We've determined that the `net::hostname` call on Windows is taking an > inordinate amount of time, and this is problematic when every instantiation > of a master or agent uses it, especially across hundreds of tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-6101) Add event for Framwork added to master operator API
[ https://issues.apache.org/jira/browse/MESOS-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quinn reassigned MESOS-6101: Assignee: Quinn (was: Zhitao Li) > Add event for Framwork added to master operator API > --- > > Key: MESOS-6101 > URL: https://issues.apache.org/jira/browse/MESOS-6101 > Project: Mesos > Issue Type: Task >Reporter: Zhitao Li >Assignee: Quinn > > Consider the following case: > 1) a subscriber connects to master; > 2) a new scheduler registered as a new framework; > 3) a task is launched from this framework. > In this sequence, subscriber does not have a way to know the FrameworkInfo > belonging to the FrameworkId. > We should support an event (e.g. when framework info in master is > added/changed). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7630) Add simple filtering to unversioned operator API
[
https://issues.apache.org/jira/browse/MESOS-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080973#comment-16080973
]
Quinn commented on MESOS-7630:
--
https://reviews.apache.org/r/60279/
https://reviews.apache.org/r/60716/
https://reviews.apache.org/r/60580/
https://reviews.apache.org/r/60581/
> Add simple filtering to unversioned operator API
>
>
> Key: MESOS-7630
> URL: https://issues.apache.org/jira/browse/MESOS-7630
> Project: Mesos
> Issue Type: Improvement
> Components: agent, master
>Reporter: Quinn
>Assignee: Quinn
> Labels: agent, api, http, master, mesosphere
>
> Add filtering for the following endpoints:
> - {{/frameworks}}
> - {{/slaves}}
> - {{/tasks}}
> - {{/containers}}
> We should investigate whether we should use RESTful style or query string to
> filter the specific resource. We should also figure out whether it's
> necessary to filter a list of resources.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-7602) Add filtering capabilities to the master/agent operator APIs
[ https://issues.apache.org/jira/browse/MESOS-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann reassigned MESOS-7602: Assignee: Quinn > Add filtering capabilities to the master/agent operator APIs > > > Key: MESOS-7602 > URL: https://issues.apache.org/jira/browse/MESOS-7602 > Project: Mesos > Issue Type: Epic > Components: agent, HTTP API, master >Reporter: Greg Mann >Assignee: Quinn > Labels: api, http, mesosphere > > We would like to add filtering capabilities to both the unversioned operator > HTTP endpoints and the V1 operator APIs on the master and agent. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7089) Local Docker Resolver for Mesos Containerizer
[ https://issues.apache.org/jira/browse/MESOS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080946#comment-16080946 ] Vinod Kone commented on MESOS-7089: --- If this is still active please add an assignee and find a shepherd. > Local Docker Resolver for Mesos Containerizer > - > > Key: MESOS-7089 > URL: https://issues.apache.org/jira/browse/MESOS-7089 > Project: Mesos > Issue Type: Story >Reporter: Santhosh Kumar Shanmugham > > Docker’s mutable tags serve as a layer of indirection which can be used to > point a tag to different images digests (concrete immutable images) at > different points in time. For instance `latest` tag can point `digest-0` at > t0 and then to `digest-1` at t1. Mesos has support for local docker registry, > where the images are files on the local filesystem, named either as > `repo:tag` or `repo@digest`. This approach trims the degree of freedom > provided by the indirection mentioned above (from Docker’s mutable tags), > which can be essential in some cases. For instance, it might be useful in > cases, where the operator of a cluster would like to rollout image updates > without having the customers to update their task configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-1623) Separate large .cpp
[ https://issues.apache.org/jira/browse/MESOS-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman reassigned MESOS-1623: --- Assignee: Benjamin Hindman > Separate large .cpp > --- > > Key: MESOS-1623 > URL: https://issues.apache.org/jira/browse/MESOS-1623 > Project: Mesos > Issue Type: Story >Reporter: Isabel Jimenez >Assignee: Benjamin Hindman > Attachments: compile.csv > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-3176) Replicate *nix permission logic in Windows using the NTFS ACL API.
[
https://issues.apache.org/jira/browse/MESOS-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Coffler reassigned MESOS-3176:
---
Assignee: Jeff Coffler (was: Li Li)
> Replicate *nix permission logic in Windows using the NTFS ACL API.
> --
>
> Key: MESOS-3176
> URL: https://issues.apache.org/jira/browse/MESOS-3176
> Project: Mesos
> Issue Type: Task
> Components: containerization, stout
>Reporter: Alex Clemmer
>Assignee: Jeff Coffler
> Labels: containerizer, stout
>
> From a forthcoming comment in stout/windows/permissions.hpp:
> {code}
> // TODO(hausdorff): (Tracked as MESOS-3176) On Windows, we currently don't
> // support User, Group, or "Other" permissions -- everyone is in one big
> // group; we also currently only support setting write permissions (i.e.,
> // everyone can write, or no one can) -- so, on Windows agents, any user can
> // read and execute a file.
> //
> // WHY: Currently we're using the DOS permissions model because it's easier.
> // In the long term we want Windows agents to replicate the *nix model of
> file
> // permissions by transitioning from the DOS model to the NTFS ACL API.
> This,
> // however, is a significant work item in itself, and will not be done for
> // the Windows MVP.
> //
> // The longer story is, the permissions model we currently use is the
> // (extremely primitive) DOS model. The CliffsNotes version of the DOS
> // permission model follows:
> //
> // * There is one type of privilege: write privilege.
> // * All files can be read
> // * Therefore, there is no native notion of "User", "Group", or "Other"
> // permissions.
> // * There is no concept whatsoever of execute permissions; if a file can
> // be read (and it definitely can), and if it's a binary, you have
> // execute permissions.
> // * All in all: the DOS model is arguably ok for situations where there
> is
> // a single user in a location that can be considered "secure."
> //
> // The practical impact of this is that most of the permissions-oriented
> APIs
> // in Stout will _pretend_ to set appropriate permissions on Windows, but
> // mostly set them to "global writable" instead.
> //
> // This is clearly not the ideal permissions scenario for Mesos. The other
> // option is to use the NTFS Access Control List (ACL) API, and in the long
> // term we will want to transition to that. The CliffsNotes version of the
> // ACL permission model is as follows:
> //
> // * An ACL is a list of security specifications (each specification is
> // known as an "Access Control Entry") that describes the access model
> of
> // an "object." An "object can be a process, a file, an event, or
> // anything else that has a security descriptor.
> // * Privileges can be granted by a process with required privileges.
> // * The ACL model is very fine-grained: access can be granted to a user,
> a
> // group, or "other", and can be split up by read, write, and execute
> // permissions.
> //
> // BUT, and here is the kicker, the ACL model is dramatically more
> // complicated, and not worth doing in the MVP. Our goal in the future is to
> // find a more permanent solution; for now, we have a non-invasive
> Unix-based
> // permission model, and that will work for now.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7602) Add filtering capabilities to the master/agent operator APIs
[ https://issues.apache.org/jira/browse/MESOS-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann updated MESOS-7602: - Shepherd: Greg Mann > Add filtering capabilities to the master/agent operator APIs > > > Key: MESOS-7602 > URL: https://issues.apache.org/jira/browse/MESOS-7602 > Project: Mesos > Issue Type: Epic > Components: agent, HTTP API, master >Reporter: Greg Mann >Assignee: Quinn > Labels: api, http, mesosphere > > We would like to add filtering capabilities to both the unversioned operator > HTTP endpoints and the V1 operator APIs on the master and agent. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-5605) Improve documentation for using persistent volumes.
[ https://issues.apache.org/jira/browse/MESOS-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone reassigned MESOS-5605: - Assignee: Joerg Schad Do you still want to land these? If yes, can you please find a shepherd? > Improve documentation for using persistent volumes. > > > Key: MESOS-5605 > URL: https://issues.apache.org/jira/browse/MESOS-5605 > Project: Mesos > Issue Type: Documentation >Reporter: Joerg Schad >Assignee: Joerg Schad > > When using persistent volumes at a arangoDB we ran into a few pitfalls. > We should document them in order for others to avoid those issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-1623) Separate large .cpp
[ https://issues.apache.org/jira/browse/MESOS-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman reassigned MESOS-1623: --- Assignee: (was: Benjamin Hindman) > Separate large .cpp > --- > > Key: MESOS-1623 > URL: https://issues.apache.org/jira/browse/MESOS-1623 > Project: Mesos > Issue Type: Story >Reporter: Isabel Jimenez > Attachments: compile.csv > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-2386) Provide full filesystem isolation as a native mesos isolator
[ https://issues.apache.org/jira/browse/MESOS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080930#comment-16080930 ] Gilbert Song commented on MESOS-2386: - [~dhamon], I am closing this epic. Please reach out and we can open other improvement epic if anything is still needed. Thanks! > Provide full filesystem isolation as a native mesos isolator > > > Key: MESOS-2386 > URL: https://issues.apache.org/jira/browse/MESOS-2386 > Project: Mesos > Issue Type: Epic > Components: containerization >Affects Versions: 0.22.1 >Reporter: Dominic Hamon > Labels: mesosphere, twitter > > Design > https://docs.google.com/a/twitter.com/document/d/1Fx5TS0LytV7u5MZExQS0-g-gScX2yKCKQg9UPFzhp6U/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-2386) Provide full filesystem isolation as a native mesos isolator
[ https://issues.apache.org/jira/browse/MESOS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080927#comment-16080927 ] Gilbert Song commented on MESOS-2386: - [~dhamon], in favor of unified containerizer MESOS-2840 and Linux filesystem support, could we close this epic? /cc [~jieyu] [~benjaminhindman] > Provide full filesystem isolation as a native mesos isolator > > > Key: MESOS-2386 > URL: https://issues.apache.org/jira/browse/MESOS-2386 > Project: Mesos > Issue Type: Epic > Components: containerization >Affects Versions: 0.22.1 >Reporter: Dominic Hamon > Labels: mesosphere, twitter > > Design > https://docs.google.com/a/twitter.com/document/d/1Fx5TS0LytV7u5MZExQS0-g-gScX2yKCKQg9UPFzhp6U/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-2952) Provide user namespaces for privileged access inside containers
[ https://issues.apache.org/jira/browse/MESOS-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu reassigned MESOS-2952: - Assignee: (was: Vaibhav Khanduja) > Provide user namespaces for privileged access inside containers > --- > > Key: MESOS-2952 > URL: https://issues.apache.org/jira/browse/MESOS-2952 > Project: Mesos > Issue Type: Epic >Reporter: Paul Brett > > User namespaces allow per-namespace mappings of user and group IDs. This > means that a process's user and group IDs inside a user namespace can be > different from its IDs outside of the namespace. Most notably, a process can > have a nonzero user ID outside a namespace while at the same time having a > user ID of zero inside the namespace; in other words, the process is > unprivileged for operations outside the user namespace but has root > privileges inside the namespace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-3537) Allow the frameworks to specify filesystem perms for volumes they own.
[
https://issues.apache.org/jira/browse/MESOS-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-3537:
--
Component/s: containerization
> Allow the frameworks to specify filesystem perms for volumes they own.
> --
>
> Key: MESOS-3537
> URL: https://issues.apache.org/jira/browse/MESOS-3537
> Project: Mesos
> Issue Type: Task
> Components: containerization
>Reporter: Yan Xu
>
> This is applicable to persistent volumes as well as regular volumes with the
> host path under the sandbox.
> Currently these volumes are created by the slave with perms from its own
> umask. In order to simulate system directories from the host sandbox the
> users may need to request certain perms (e.g. {{/var/www-data}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-2386) Provide full filesystem isolation as a native mesos isolator
[ https://issues.apache.org/jira/browse/MESOS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song reassigned MESOS-2386: --- Assignee: Jie Yu > Provide full filesystem isolation as a native mesos isolator > > > Key: MESOS-2386 > URL: https://issues.apache.org/jira/browse/MESOS-2386 > Project: Mesos > Issue Type: Epic > Components: containerization >Affects Versions: 0.22.1 >Reporter: Dominic Hamon >Assignee: Jie Yu > Labels: mesosphere, twitter > > Design > https://docs.google.com/a/twitter.com/document/d/1Fx5TS0LytV7u5MZExQS0-g-gScX2yKCKQg9UPFzhp6U/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MESOS-7776) Document `MESOS_CONTAINER_IP`
Avinash Sridharan created MESOS-7776: Summary: Document `MESOS_CONTAINER_IP` Key: MESOS-7776 URL: https://issues.apache.org/jira/browse/MESOS-7776 Project: Mesos Issue Type: Documentation Components: containerization Reporter: Avinash Sridharan Assignee: Avinash Sridharan We introduced `MESOS_CONTAINER_IP` to inform tasks launched by the default-executor to inform the tasks about their container IP. This was done primarily to break the dependency of the containers on `LIBPROCESS_IP` to learn their IP addresses which was misleading. This change need to be documented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7770) Persistent volume might not be mounted if there is a sandbox volume whose source is the same as the target of the persistent volume.
[ https://issues.apache.org/jira/browse/MESOS-7770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-7770: Story Points: 3 Labels: mesosphere persistent-volumes (was: ) Component/s: containerization > Persistent volume might not be mounted if there is a sandbox volume whose > source is the same as the target of the persistent volume. > > > Key: MESOS-7770 > URL: https://issues.apache.org/jira/browse/MESOS-7770 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 1.1.2, 1.2.1, 1.3.0 >Reporter: Jie Yu >Assignee: Gilbert Song >Priority: Critical > Labels: mesosphere, persistent-volumes > > This issue is only for Mesos Containerizer. > If the source of a sandbox volume is a relative path, we'll create the > directory in the sandbox in Isolator::prepare method: > https://github.com/apache/mesos/blob/1.3.x/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp#L480-L485 > And then, we'll try to mount persistent volumes. However, because of this > TODO in the code: > https://github.com/apache/mesos/blob/1.3.x/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp#L726-L739 > We'll skip mounting the persistent volume. That will cause a silent failure. > This is important because the workaround we suggest folks to solve MESOS-4016 > is to use an additional sandbox volume. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-7469) Add resource provider driver.
[ https://issues.apache.org/jira/browse/MESOS-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu reassigned MESOS-7469: - Assignee: Benjamin Bannier (was: Qian Zhang) > Add resource provider driver. > - > > Key: MESOS-7469 > URL: https://issues.apache.org/jira/browse/MESOS-7469 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: Benjamin Bannier > > Similar to scheduler/executor driver, resource provider driver will be used > to connect the resource provider and the Resource provider manager (resides > in either agent for local resource providers, or master for external resource > providers). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7658) apply-reviews.py fails with Unicode characters
[
https://issues.apache.org/jira/browse/MESOS-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-7658:
Environment: (was: Windows 10, OS X)
Summary: apply-reviews.py fails with Unicode characters (was:
apply-reviews.py fails with Unicode characters on Windows)
Turns out this is failing not only on Windows and macOS, but also one Linux.
> apply-reviews.py fails with Unicode characters
> --
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
> Issue Type: Bug
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
> File ".\support\apply-reviews.py", line 381, in
> reviewboard()
> File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
> File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
> File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
> File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT,
> shell=True)
> File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
> File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows
[
https://issues.apache.org/jira/browse/MESOS-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-7658:
Environment: Windows 10, OS X (was: Windows 10)
> apply-reviews.py fails with Unicode characters on Windows
> -
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
> Issue Type: Bug
> Environment: Windows 10, OS X
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
> File ".\support\apply-reviews.py", line 381, in
> reviewboard()
> File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
> File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
> File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
> File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT,
> shell=True)
> File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
> File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows
[
https://issues.apache.org/jira/browse/MESOS-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080522#comment-16080522
]
Benjamin Bannier edited comment on MESOS-7658 at 7/10/17 3:42 PM:
--
The same problem occurs under OS X as well, e.g., a commit with the following
commit message cannot be applied,
{quote}
Docs are very nice btw, thanks ! 😃
{quote}
was (Author: bbannier):
The same problem occurs under OS X as well, e.g., a commit with the following
commit message cannot be applied,
> Docs are very nice btw, thanks ! 😃
> apply-reviews.py fails with Unicode characters on Windows
> -
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
> Issue Type: Bug
> Environment: Windows 10
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
> File ".\support\apply-reviews.py", line 381, in
> reviewboard()
> File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
> File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
> File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
> File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT,
> shell=True)
> File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
> File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7658) apply-reviews.py fails with Unicode characters on Windows
[
https://issues.apache.org/jira/browse/MESOS-7658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080522#comment-16080522
]
Benjamin Bannier commented on MESOS-7658:
-
The same problem occurs under OS X as well, e.g., a commit with the following
commit message cannot be applied,
> Docs are very nice btw, thanks ! 😃
> apply-reviews.py fails with Unicode characters on Windows
> -
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
> Issue Type: Bug
> Environment: Windows 10
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>
> This prevents commits from being applied if the name or message contains
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
> File ".\support\apply-reviews.py", line 381, in
> reviewboard()
> File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
> File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
> File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
> File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT,
> shell=True)
> File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
> File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-5329) Unable to build on ARM64/AArch64 when using bundled 3rdparty libs
[ https://issues.apache.org/jira/browse/MESOS-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080507#comment-16080507 ] Ed Vielmetti commented on MESOS-5329: - I'm also unable to build Mesos on ARM64. The version of "glog" used fails with this error: ``` UNAME_MACHINE = aarch64 UNAME_RELEASE = 4.4.0-77-generic UNAME_SYSTEM = Linux UNAME_VERSION = #98-Ubuntu SMP Wed Apr 26 08:34:20 UTC 2017 configure: error: cannot guess build type; you must specify one Makefile:1148: recipe for target 'glog-0.3.3-build-stamp' failed ``` It looks like MESOS-3394 may be related, having to do with versioning of glog for Windows. > Unable to build on ARM64/AArch64 when using bundled 3rdparty libs > - > > Key: MESOS-5329 > URL: https://issues.apache.org/jira/browse/MESOS-5329 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.28.1 > Environment: I'm using openSUSE Tumbleweed: > - uname -a = Linux od3k 4.5.0-3-default #1 SMP Mon Mar 28 07:27:57 UTC 2016 > (8cf0ce6) aarch64 aarch64 aarch64 GNU/Linux > - gcc --version = gcc (SUSE Linux) 5.3.1 20160301 [gcc-5-branch revision > 233849] > - java -version = openjdk version "9-internal" > OpenJDK Runtime Environment (build > 9-internal+0-2016-04-12-223414.abuild.jdk9-55b6d550828d) > OpenJDK 64-Bit Server VM (build > 9-internal+0-2016-04-12-223414.abuild.jdk9-55b6d550828d, mixed mode) > on an [Overdrive 3000|http://softiron.co.uk/products/] >Reporter: Andrew Wafaa > Labels: easyfix > > Some of the supplied 3rdparty libraries are so outdated they do not have > support for 64bit ARM. The following need to be updated before you can build > from mesos source: > * protobuf 2.5.0 -> 2.6.1 > * libev 4.15 -> 4.22 > If I disable the 3rdparty libraries and use those supplied by the OS all > builds fine. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-3394) Change glog download target for Windows when pull req is moved upstream
[ https://issues.apache.org/jira/browse/MESOS-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080509#comment-16080509 ] Ed Vielmetti commented on MESOS-3394: - The release of glog 0.3.5 that includes this fix has been published, at https://github.com/google/glog/releases/tag/v0.3.5 > Change glog download target for Windows when pull req is moved upstream > --- > > Key: MESOS-3394 > URL: https://issues.apache.org/jira/browse/MESOS-3394 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Andrew Schwartzmeyer > Labels: build, cmake, mesosphere > > To build on Windows, we have to build glog on Windows. But, glog doesn't > build on Windows, so we had to submit a patch to the project. So, to build on > Windows, we download the patched version directly from the pull request that > was sent to the glog repository on GitHub. > When these patches move upstream, we need to change this to point at the > "real" glog release instead of the pull request. > (For details see the `CMakeLists.txt` in `3rdparty/libprocess/3rdparty`.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MESOS-7775) Eliminate extra process abort in a subprocess watchdog
Andrei Budnik created MESOS-7775: Summary: Eliminate extra process abort in a subprocess watchdog Key: MESOS-7775 URL: https://issues.apache.org/jira/browse/MESOS-7775 Project: Mesos Issue Type: Bug Reporter: Andrei Budnik `abort()` is called in `SUPERVISOR` hook when child process exits with an error code, or `waitpid()` fails, or parent process exits. All these cases shouldn't lead to abnormal program termination with coredumps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-7775) Eliminate extra process abort in a subprocess watchdog
[ https://issues.apache.org/jira/browse/MESOS-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Budnik reassigned MESOS-7775: Assignee: Andrei Budnik > Eliminate extra process abort in a subprocess watchdog > -- > > Key: MESOS-7775 > URL: https://issues.apache.org/jira/browse/MESOS-7775 > Project: Mesos > Issue Type: Bug >Reporter: Andrei Budnik >Assignee: Andrei Budnik > > `abort()` is called in `SUPERVISOR` hook when child process exits with an > error code, or `waitpid()` fails, or parent process exits. All these cases > shouldn't lead to abnormal program termination with coredumps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-5998) FINISHED task shown as Active in the UI
[ https://issues.apache.org/jira/browse/MESOS-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080197#comment-16080197 ] Benjamin Bannier commented on MESOS-5998: - This issue can be caused if the "owning" framework has not yet been delivered the last status update of terminal tasks. I created MESOS-7774 for the more general issue, and am closing this one as a dup. > FINISHED task shown as Active in the UI > --- > > Key: MESOS-5998 > URL: https://issues.apache.org/jira/browse/MESOS-5998 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 1.0.0 >Reporter: Michael Gummelt > > http://mgummelt-mesos.s3.amazonaws.com/ui_screenshot.png -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7774) Consider more clearly distinguishing "zombie" tasks from other tasks in webui
[
https://issues.apache.org/jira/browse/MESOS-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-7774:
Issue Type: Improvement (was: Bug)
> Consider more clearly distinguishing "zombie" tasks from other tasks in webui
> -
>
> Key: MESOS-7774
> URL: https://issues.apache.org/jira/browse/MESOS-7774
> Project: Mesos
> Issue Type: Improvement
> Components: webui
>Reporter: Benjamin Bannier
> Labels: mesosphere
>
> The webui's home page displays a list of active tasks; this list is
> constructed from the list of non-completed framework tasks. If a framework
> has not yet acknowledged a terminal status update, the list of "active tasks"
> can contain tasks in terminal states which is confusing to users, e.g.,
> * launch {{sleep 10}} with {{mesos-execute}}
> * after the task is launch suspend the {{mesos-execute}} process
> * after 10s the list of active tasks contains a {{FINISHED}} task
> or
> * launch {{sleep 10}} with {{mesos-execute}}
> * after the task is launch suspend the {{mesos-execute}} process
> * kill the {{sleep}} system process
> * the list of active tasks contains a {{FAILED}} task
> The underlying issue here is that what is displayed in the webui very
> directly reflects the list of tasks in {{master}} {{Framework}} objects.
> There {{tasks}} holds tasks the master needs to track (since they might e.g.,
> still be running, or the frameworks need to be notified of status changes,
> etc.), while e.g. {{completedTasks}} holds tasks of just historic interest
> since they do not anymore require any master actions.
> Exposing this information in such an unfiltered way is likely confusing.
> While this applies to the {{state}} endpoint like it does to the webui, a fix
> should be easier to accomplish in the ui. We could there add some (visual?)
> clue that active tasks in terminal states are analogous to zombie processes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7774) Consider more clearly distinguishing "zombie" tasks from other tasks in webui
Benjamin Bannier created MESOS-7774:
---
Summary: Consider more clearly distinguishing "zombie" tasks from
other tasks in webui
Key: MESOS-7774
URL: https://issues.apache.org/jira/browse/MESOS-7774
Project: Mesos
Issue Type: Bug
Components: webui
Reporter: Benjamin Bannier
The webui's home page displays a list of active tasks; this list is constructed
from the list of non-completed framework tasks. If a framework has not yet
acknowledged a terminal status update, the list of "active tasks" can contain
tasks in terminal states which is confusing to users, e.g.,
* launch {{sleep 10}} with {{mesos-execute}}
* after the task is launch suspend the {{mesos-execute}} process
* after 10s the list of active tasks contains a {{FINISHED}} task
or
* launch {{sleep 10}} with {{mesos-execute}}
* after the task is launch suspend the {{mesos-execute}} process
* kill the {{sleep}} system process
* the list of active tasks contains a {{FAILED}} task
The underlying issue here is that what is displayed in the webui very directly
reflects the list of tasks in {{master}} {{Framework}} objects. There {{tasks}}
holds tasks the master needs to track (since they might e.g., still be running,
or the frameworks need to be notified of status changes, etc.), while e.g.
{{completedTasks}} holds tasks of just historic interest since they do not
anymore require any master actions.
Exposing this information in such an unfiltered way is likely confusing. While
this applies to the {{state}} endpoint like it does to the webui, a fix should
be easier to accomplish in the ui. We could there add some (visual?) clue that
active tasks in terminal states are analogous to zombie processes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-5361) Consider introducing TCP KeepAlive for Libprocess sockets.
[
https://issues.apache.org/jira/browse/MESOS-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Pronin reassigned MESOS-5361:
--
Assignee: (was: Ilya Pronin)
> Consider introducing TCP KeepAlive for Libprocess sockets.
> --
>
> Key: MESOS-5361
> URL: https://issues.apache.org/jira/browse/MESOS-5361
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Anand Mazumdar
> Labels: mesosphere
>
> We currently don't use TCP KeepAlive's when creating sockets in libprocess.
> This might benefit master - scheduler, master - agent connections i.e. we can
> detect if any of them failed faster.
> Currently, if the master process goes down. If for some reason the {{RST}}
> sequence did not reach the scheduler, the scheduler can only come to know
> about the disconnection when it tries to do a {{send}} itself.
> The default TCP keep alive values on Linux are of little use in a real world
> application:
> {code}
> . This means that the keepalive routines wait for two hours (7200 secs)
> before sending the first keepalive probe, and then resend it every 75
> seconds. If no ACK response is received for nine consecutive times, the
> connection is marked as broken.
> {code}
> However, for long running instances of scheduler/agent this still can be
> beneficial. Also, operators might start tuning the values for their clusters
> explicitly once we start supporting it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7773) HTTP request validation stage is not explicit.
Alexander Rukletsov created MESOS-7773:
--
Summary: HTTP request validation stage is not explicit.
Key: MESOS-7773
URL: https://issues.apache.org/jira/browse/MESOS-7773
Project: Mesos
Issue Type: Bug
Components: libprocess
Reporter: Alexander Rukletsov
Currently we validate HTTP requests in multiple places in libprocess, for
instance {{ProcessManager::handle()}}, {{StreamingRequestDecoder::decode()}},
{{process::parse()}}. To improve error handling when dealing with malformed
HTTP requests (including libprocess messages), consider introducing a
validation stage or make sure {{Request}} and all its components are in valid
state before we start using it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7773) HTTP request validation stage is not explicit.
[
https://issues.apache.org/jira/browse/MESOS-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-7773:
---
Description: Currently we validate HTTP requests in multiple places in
libprocess, for instance {{ProcessManager::handle()}},
{{StreamingRequestDecoder::decode()}}, {{process::parse()}}. To improve error
handling when dealing with malformed HTTP requests (including libprocess
messages), consider introducing a validation stage and / or make sure
{{Request}} and all its components are in valid state before we start using it.
(was: Currently we validate HTTP requests in multiple places in libprocess,
for instance {{ProcessManager::handle()}},
{{StreamingRequestDecoder::decode()}}, {{process::parse()}}. To improve error
handling when dealing with malformed HTTP requests (including libprocess
messages), consider introducing a validation stage or make sure {{Request}} and
all its components are in valid state before we start using it.)
> HTTP request validation stage is not explicit.
> --
>
> Key: MESOS-7773
> URL: https://issues.apache.org/jira/browse/MESOS-7773
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Alexander Rukletsov
>
> Currently we validate HTTP requests in multiple places in libprocess, for
> instance {{ProcessManager::handle()}}, {{StreamingRequestDecoder::decode()}},
> {{process::parse()}}. To improve error handling when dealing with malformed
> HTTP requests (including libprocess messages), consider introducing a
> validation stage and / or make sure {{Request}} and all its components are in
> valid state before we start using it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7689) Libprocess can crash on malformed request paths for libprocess messages.
[
https://issues.apache.org/jira/browse/MESOS-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080023#comment-16080023
]
Alexander Rukletsov commented on MESOS-7689:
{noformat}
Commit: 1da4e45b8077b9046bba1a7ed15be5e344a14a91 [1da4e45]
Author: Alexander Rukletsov
Date: 4 July 2017 at 15:24:17 GMT+2
Commit Date: 10 July 2017 at 09:33:00 GMT+2
Rejected libprocess HTTP requests with empty path.
Without this patch, a malicious actor can crash libprocess-based
components by sending a libprocess HTTP message with empty path.
For robustness, we check for malformed HTTP requests in both
handle() and parse() routines in libprocess, because there is
no guarantee that parse() will always get a validated request.
A better approach would be to introduce an explicit HTTP request
validation stage, for both libprocess and common HTTP messages.
{noformat}
> Libprocess can crash on malformed request paths for libprocess messages.
>
>
> Key: MESOS-7689
> URL: https://issues.apache.org/jira/browse/MESOS-7689
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
> Fix For: 1.2.2, 1.3.1, 1.4.0, 1.1.3
>
>
> The following code will crash when there is a libprocess message and the path
> cannot be decoded:
> https://github.com/apache/mesos/blob/1.3.0/3rdparty/libprocess/src/process.cpp#L798-L800
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
