[jira] [Created] (MESOS-9159) Support Foreign URLs in docker registry puller
Akash Gupta created MESOS-9159: -- Summary: Support Foreign URLs in docker registry puller Key: MESOS-9159 URL: https://issues.apache.org/jira/browse/MESOS-9159 Project: Mesos Issue Type: Task Reporter: Akash Gupta Currently, trying to pull the layers of a Windows image with the current registry pull code will return a 404 error. This is because the Windows docker images need to pull the base OS layers from the foreign URLs field in the version 2 schema 2 docker manifest. As a result, the register puller needs to be aware of version 2 schema 2 and the foreign urls field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8672) Replace libprocess `PollSocketImpl` with IOCP and Thread Pool API
Akash Gupta created MESOS-8672: -- Summary: Replace libprocess `PollSocketImpl` with IOCP and Thread Pool API Key: MESOS-8672 URL: https://issues.apache.org/jira/browse/MESOS-8672 Project: Mesos Issue Type: Task Reporter: Akash Gupta Assignee: Akash Gupta `io:poll` on Windows currently blocks on pipes. Furthermore, the libevent on backed on `io:poll` only works on sockets. So, we need to replace the `PollSocketImpl` with a native Windows version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8670) Implement `process::io::read/write` using Thread Pool API
Akash Gupta created MESOS-8670: -- Summary: Implement `process::io::read/write` using Thread Pool API Key: MESOS-8670 URL: https://issues.apache.org/jira/browse/MESOS-8670 Project: Mesos Issue Type: Task Reporter: Akash Gupta Assignee: Akash Gupta `process::io::read/write` currently use a read/write loop with `io:: poll`, which is implemented by the libevent loop. This doesn't work on Windows, because libevent only works on sockets. Furthermore, the reads/writes are blocking on Windows for pipes. Instead, we should use I/O completion ports with overlapped I/O and the thread pool API to implement read/write. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8669) Implement libprocess `EventLoop()` using Windows Thread Pool API
Akash Gupta created MESOS-8669: -- Summary: Implement libprocess `EventLoop()` using Windows Thread Pool API Key: MESOS-8669 URL: https://issues.apache.org/jira/browse/MESOS-8669 Project: Mesos Issue Type: Task Reporter: Akash Gupta Assignee: Akash Gupta Implement `EventLoop` using the Windows Thread Pool API in order to replace Libevent in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-8643) `os::system` and `os::spawn` returns -1 on valid windows commands
[
https://issues.apache.org/jira/browse/MESOS-8643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akash Gupta reassigned MESOS-8643:
--
Assignee: Akash Gupta
> `os::system` and `os::spawn` returns -1 on valid windows commands
> -
>
> Key: MESOS-8643
> URL: https://issues.apache.org/jira/browse/MESOS-8643
> Project: Mesos
> Issue Type: Bug
>Reporter: Akash Gupta
>Assignee: Akash Gupta
>Priority: Major
>
> `os::system` and `os::spawn` return the process exit code or -1 on failure.
> However, on WIndows, -1 is a valid exit code (e.g. `os::system("exit -1")).
> It's impossible to distinguish a failure from a process returning -1, so
> those calls need to return something like a `Try` or `Option` to
> distinguish the error case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-8644) W* macros wrong on Windows.
[ https://issues.apache.org/jira/browse/MESOS-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akash Gupta reassigned MESOS-8644: -- Assignee: Akash Gupta > W* macros wrong on Windows. > --- > > Key: MESOS-8644 > URL: https://issues.apache.org/jira/browse/MESOS-8644 > Project: Mesos > Issue Type: Bug >Reporter: Akash Gupta >Assignee: Akash Gupta >Priority: Major > > The `WIFEXITED` checks if the return code is -1 to determine if the process > has exited, but on Windows a process can legitimately return -1 as an exit > code. It's especially an issue because parts of the mesos code base use > `CHECK(WIFEXITED(exit_code) ... )`, which will throw an assertion error if > the exit_code is -1. > > Furthermore, the other W* macros determine signal handling, which doesn't > make any sense on Windows and can be misused. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8644) W* macros wrong on Windows.
Akash Gupta created MESOS-8644: -- Summary: W* macros wrong on Windows. Key: MESOS-8644 URL: https://issues.apache.org/jira/browse/MESOS-8644 Project: Mesos Issue Type: Bug Reporter: Akash Gupta The `WIFEXITED` checks if the return code is -1 to determine if the process has exited, but on Windows a process can legitimately return -1 as an exit code. It's especially an issue because parts of the mesos code base use `CHECK(WIFEXITED(exit_code) ... )`, which will throw an assertion error if the exit_code is -1. Furthermore, the other W* macros determine signal handling, which doesn't make any sense on Windows and can be misused. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8643) `os::system` and `os::spawn` returns -1 on valid windows commands
Akash Gupta created MESOS-8643:
--
Summary: `os::system` and `os::spawn` returns -1 on valid windows
commands
Key: MESOS-8643
URL: https://issues.apache.org/jira/browse/MESOS-8643
Project: Mesos
Issue Type: Bug
Reporter: Akash Gupta
`os::system` and `os::spawn` return the process exit code or -1 on failure.
However, on WIndows, -1 is a valid exit code (e.g. `os::system("exit -1")).
It's impossible to distinguish a failure from a process returning -1, so those
calls need to return something like a `Try` or `Option` to
distinguish the error case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-8566) Port container IPv6 tests to Windows
Akash Gupta created MESOS-8566: -- Summary: Port container IPv6 tests to Windows Key: MESOS-8566 URL: https://issues.apache.org/jira/browse/MESOS-8566 Project: Mesos Issue Type: Bug Reporter: Akash Gupta Assignee: Akash Gupta Windows does not currently support IPv6 in containers to due platform limitations. However, it will probably support it in the future, so we can then port the docker IPv6 tests and any other container tests that require IPv6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8535) Replace custom nanoserver image with official one
Akash Gupta created MESOS-8535: -- Summary: Replace custom nanoserver image with official one Key: MESOS-8535 URL: https://issues.apache.org/jira/browse/MESOS-8535 Project: Mesos Issue Type: Task Reporter: Akash Gupta Assignee: Akash Gupta The official `microsoft/powershell:nanoserver` image runs as ContainerUser, which has some permissions bugs with accessing volume mounts in process (but not Hyper-V) isolation. However, accessing them as ContainerAdministrator works fine, so the custom `akagup/pwsh-nano-admin` image runs as ContainerAdministrator. If this is fixed in the new Windows releases, we can use the official image. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-8498) Enable docker health checks on Windows
Akash Gupta created MESOS-8498: -- Summary: Enable docker health checks on Windows Key: MESOS-8498 URL: https://issues.apache.org/jira/browse/MESOS-8498 Project: Mesos Issue Type: Task Reporter: Akash Gupta Assignee: Akash Gupta Currently, the docker health checks do not work on Windows. They use a Linux-only method of switching process namespaces, which does not work on Windows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
