---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63271/#review190955
---
Ship it!
Ship It!
- Aaron Wood
On Nov. 14, 2017, 12:20 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63279/#review189972
---
Ship it!
Ship It!
- Aaron Wood
On Nov. 2, 2017, 8:40 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63278/#review189971
---
Ship it!
Ship It!
- Aaron Wood
On Nov. 2, 2017, 8:40 p.m
rocess IDs are multiples of 4
https://blogs.msdn.microsoft.com/oldnewthing/20080228-00/?p=23283/
They do mention that you should not rely on this behavior which is too bad.
If you could always assume this you could reduce your cycles here.
- Aaron Wood
On Nov. 2, 2017, 8:40 p.m.,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63268/#review189963
---
Ship it!
Ship It!
- Aaron Wood
On Nov. 2, 2017, 8:39 p.m
leaner to do `if (!result) {`
- Aaron Wood
On Nov. 2, 2017, 8:39 p.m., Andrew Schwartzmeyer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://re
ent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
make -j$(nproc) && make check
-j$(nproc)`
Thanks,
Aaron Wood
; make -j4`
Also spun up a master and agent, connected and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
; make -j4`
Also spun up a master and agent, connected and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
e/containerizer/mesos/launch.cpp:803: Lines should be <= 80
> > characters long [whitespace/line_length] [2]
> > src/slave/containerizer/mesos/launch.cpp:808: Lines should be <= 80
> > characters long [whitespace/line_length] [2]
> > Total errors found: 1
> >
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60280/#review179745
---
On July 5, 2017, 9:03 p.m., Aaron Wood wrote:
>
> ---
> This is an autom
; make -j4`
Also spun up a master and agent, connected and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
t set? Maybe use
> > os::realpath here to get the absolute path?
>
> Aaron Wood wrote:
> Sure, I'll alter that. Is it wrong to assume that the working directory
> will always be set at this point? I thought that without the sandbox work dir
> no container would be able to m
Mesos execute it in the usual way. If that's the case then
would we need to search `PATH` at all?
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60280/#review17965
cmake/MesosConfigure.cmake 5ecad2c0f
Diff: https://reviews.apache.org/r/60546/diff/2/
Changes: https://reviews.apache.org/r/60546/diff/1-2/
Testing
---
`mkdir build && cd build && cmake .. && make -j$(nproc) && make check
-j$(nproc)`
Thanks,
Aaron Wood
ng that the static libs built here are only for linking into
executables. Do you think this will hold true going forward?
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.o
dingly.
Thanks,
Aaron Wood
p; cmake .. -DCMAKE_BUILD_TYPE=Release && make -j4`
Also spun up a master and agent, connected and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
; make -j4`
Also spun up a master and agent, connected and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
iner would be able to move forward.
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60280/#review179433
-------
executables.
Diffs
-
cmake/CompilationConfigure.cmake 3fa2e2f3b
cmake/MesosConfigure.cmake 5ecad2c0f
Diff: https://reviews.apache.org/r/60546/diff/1/
Testing
---
`mkdir build && cd build && cmake .. && make -j$(nproc) && make check
-j$(nproc)`
Thanks,
Aaron Wood
and sent a task using the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
ng the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
e used in the full absolute path to their executor binary in the
sandbox?
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60280/#review178586
----
into the current
> > working directory?
>
> Aaron Wood wrote:
> I found that this was not true. This is the real core of the fix. It
> seems that exec will not look in the current directory, only in PATH.
`The file is sought in the colon-separated list of direct
ng the UCR (both
with and without the use of an OCI image) via our own framework, and checked
the sandbox to verify that things went accordingly.
Thanks,
Aaron Wood
> On June 21, 2017, 7:28 p.m., Aaron Wood wrote:
> > Someone correct me if I'm wrong, but I don't think we need this anymore:
> > ```
> > if (launchInfo.has_working_directory()) {
> > Try chdir = os::chdir(launchInfo.working_directory());
> > if (
. To reply, visit:
https://reviews.apache.org/r/60280/#review178562
-------
On June 21, 2017, 7:15 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail.
y() << "': "
<< chdir.error() << endl;
exitWithStatus(EXIT_FAILURE);
}
}
```
Everyone okay with me removing this?
- Aaron Wood
On June 21, 2017, 7:15 p.m., Aaron Wood wrote:
>
> -
andbox to verify that things went accordingly.
Thanks,
Aaron Wood
,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stderr","size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
;,"size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stderr","size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
;,"size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
;,"size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
would do the shadow variable fix in a separate dependent review
> > instead of mixing it here.
I'll revert my naming changes here. Why is it that this kind of change needs a
separate patch?
- Aaron
---
This is an automatically generated
;,"size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
ly generated e-mail. To reply, visit:
https://reviews.apache.org/r/59641/#review176325
---
On May 30, 2017, 6:10 p.m., Aaron Wood wrote:
>
> ---
> This is an automatica
ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stderr","size":255,"uid":"root"},{"gid":"root","mode":"-rw-r--r--","mtime":1496161812.0,"nlink":1,"path":"\/tmp\/slave\/slaves\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-S0\/frameworks\/d3566e51-4d13-4ed1-b66b-d538d3d7ef28-0001\/executors\/testapp-924b5c1524d84676a6a71665e2054d31\/runs\/latest\/stdout","size":1142,"uid":"root"}]
```
Thanks,
Aaron Wood
://reviews.apache.org/r/59413/diff/5/
Testing (updated)
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc) &&
make check -j$(nproc)`
Thanks,
Aaron Wood
le-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59536/#review175985
---
Ship it!
Ship It!
- Aaron Wood
On May 24, 2017, 7:13 p.m
verifying the
hashes.
- Aaron Wood
On May 24, 2017, 7:13 p.m., Andrew Schwartzmeyer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache
-----
On May 24, 2017, 5:53 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59454/
>
mize --disable-hardening && make check -j$(nproc)`
Thanks,
Aaron Wood
/59454/diff/1/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make check -j$(nproc)`
Thanks,
Aaron Wood
://reviews.apache.org/r/59413/diff/4/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
&& mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
ight also be worth waiting to see if GCC upstream is going to fix the
> > problem promptly. If GCC 7.2 fixes the problem, we don't necessarily need
> > to workaround a bug that occurs in just a single minor release of GCC.
>
> Aaron Wood wrote:
> Sure, I can hold on this
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
/diff/2-3/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
his is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59413/#review17
---
On May 19, 2017, 6:51 p.m., Aaron Wood wrote:
>
> -
/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
mize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
9af- 'ID must not be greater
than 255 characters'
```
Thanks,
Aaron Wood
---
On April 10, 2017, 10:37 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58317/
> -
'ID must not be greater
than 255 characters'
```
Thanks,
Aaron Wood
> On April 10, 2017, 9:05 p.m., Aaron Wood wrote:
> > src/common/validation.cpp
> > Lines 40 (patched)
> > <https://reviews.apache.org/r/58317/diff/1/?file=1687524#file1687524line40>
> >
> > Maybe it's better to put this check in `src/slave/paths.cpp`
al pieces.
I could add this check around here:
```
const string directory =
getExecutorRunPath(rootDir, slaveId, frameworkId, executorId,
containerId);
Try mkdir = os::mkdir(directory);
```
Thoughts?
- Aaron Wood
On April 10, 2017, 6:16 p.m., Aaron W
)
<https://reviews.apache.org/r/58317/#comment244396>
I figured I'd fix this spelling error while I was here.
- Aaron Wood
On April 10, 2017, 6:16 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail.
outhewhtiewtwetwhtohwethwetwehtwehtwjethwejlthwejlthwejhtwejthwejkthwejkthwejkthwejthwkthwekthwtkjwthkwjehtjkwehtkjwehtkjwehtkjwehtkwejhtewjkthewkjthewjkthwekjthwekjthwekjthwekjthwekjhtwekhtewkapplication227741021670-4A491BFF-F50D-4F17-B304-AD23423F15EE
of framework 9e8d9439-7ed2-4968-a8cb-f46273c2d9af- 'ID must not be greater
than 255 characters'
```
Thanks,
Aaron Wood
--
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54993/#review160160
---
On Dec. 22, 2016, 9:10 p.m., Aaron Wood wrote:
>
> --
d by making sure no segfault occurs when rebuilding Mesos with this fix
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
f/
Testing
---
Verified by making sure no segfault occurs when rebuilding Mesos with this fix
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
mework at it. Our framework is currently not generating v4
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
ith this fix
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55480/#review161484
-------
On Jan. 12, 2017, 11:52 p.m., Aaron Wood wrote:
>
> --
s which was exposing the issue.
Thanks,
Aaron Wood
x
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was causing the issue.
Thanks,
Aaron Wood
Wood
On Jan. 12, 2017, 11:23 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55480/
> ---
&g
e/validation.cpp abd9b1248
Diff: https://reviews.apache.org/r/55480/diff/
Testing
---
Verified by making sure no segfault occurs when rebuilding Mesos with this fix
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was causing the issue.
Thanks,
Aaron Wood
, not with the
posix_launcher).
`make check -j4` also passes with no errors.
Thanks,
Aaron Wood
, not with the
posix_launcher).
`make check -j4` also passes with no errors.
Thanks,
Aaron Wood
visit:
https://reviews.apache.org/r/54996/#review160821
-------
On Jan. 4, 2017, 9:55 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generat
happened with Mesos containerizer + linux_launcher, not with the
posix_launcher).
Thanks,
Aaron Wood
tps://reviews.apache.org/r/54996/#comment231691>
Looks like `posix_memalign` never sets `errno`. Need to change this to
return `Error`.
- Aaron Wood
On Jan. 4, 2017, 9:28 p.m., Aaron Wood wrote:
>
> ---
> This is an automatica
> > ```
> > void * Stack::start() {
> > return (uint8_t *)address + size;
> > }
> > ```
>
> Aaron Wood wrote:
> Don't we want to avoid C-style casts?
>
> James Peach wrote:
> Sure, you could `static_cast` here. Not much d
-
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54996/#review160464
---
On Jan. 4, 2017, 9:28 p.m., Aaron Wood wrote:
>
> --
nt below about why the copy constructor cannot be deleted in this case.
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54996/#review160464
---
On Jan. 4, 2017, 9:28 p.m., Aaron Wood wrote:
>
>
> > ```
> > void * Stack::start() {
> > return (uint8_t *)address + size;
> > }
> > ```
>
> Aaron Wood wrote:
> Don't we want to avoid C-style casts?
>
> James Peach wrote:
> Sure, you could `static_cast` here. Not much d
");
> > }
> >
> > return stack;
> > }
> > ```
> >
> > We can get rid of the `allocate` function. Once created, it's by
> > default allocated.
>
> Aaron Wood wrote:
> `address` and `size` wo
, not with the
posix_launcher).
Thanks,
Aaron Wood
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54996/#review160513
---
On Jan. 4, 2017, 12:26 a.m., Aaron Wood wrote:
>
> ---
> This is an automaticall
> > ```
> > void * Stack::start() {
> > return (uint8_t *)address + size;
> > }
> > ```
>
> Aaron Wood wrote:
> Don't we want to avoid C-style casts?
>
> James Peach wrote:
> Sure, you could `static_cast` here. Not much
il. To reply, visit:
https://reviews.apache.org/r/54996/#review160464
-------
On Jan. 4, 2017, 12:26 a.m., Aaron Wood wrote:
>
> ---
> This is an automat
tps://reviews.apache.org/r/54996/#comment231598>
Anyone see a way around this reinterpret_cast?
- Aaron Wood
On Jan. 4, 2017, 12:26 a.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply,
currently running it in a test cluster. Launched
both Docker and Mesos tasks via Marathon without any resulting crash (initial
crash only happened with Mesos containerizer + linux_launcher, not with the
posix_launcher).
Thanks,
Aaron Wood
/54996/#review160159
---
On Dec. 29, 2016, 7:03 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.ap
).
Thanks,
Aaron Wood
, not with the
posix_launcher).
Thanks,
Aaron Wood
Mesos on ARM64 with no failures. Mesos also properly starts and
successfully runs/launches tasks with the exception of a crash when using the
linux_launcher and Mesos containers. That fix is addressed in
https://reviews.apache.org/r/54996/
Thanks,
Aaron Wood
and am currently running it in a test cluster. Launched
both Docker and Mesos tasks via Marathon without any resulting crash (initial
crash only happened with Mesos containerizer + linux_launcher, not with the
posix_launcher).
Thanks,
Aaron Wood
Mesos on ARM64 with no failures. Mesos also properly starts and
successfully runs with the exception of an issue with Mesos containers
(addressed in https://reviews.apache.org/r/54996/).
Thanks,
Aaron Wood
Mesos on ARM64 with no failures. Mesos also properly starts and
successfully runs with the exception of an issue with Mesos containers
(addressed in a separate review).
Thanks,
Aaron Wood
properly starts and
successfully runs with the exception of an issue with Mesos containers
(addressed in a separate review).
Thanks,
Aaron Wood
e-python --disable-java --disable-hardening && make
Thanks,
Aaron Wood
u're right, good catch.
- Aaron
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54953/#review159886
---
On Dec. 21, 2
hardening.
Diffs
-
src/Makefile.am abcf7eed7
Diff: https://reviews.apache.org/r/54953/diff/
Testing
---
../configure --disable-python --disable-java && make
../configure --disable-python --disable-java --disable-hardening && make
Thanks,
Aaron Wood
is applied to
MESOS_CPPFLAGS thus failing the whole build.
Diffs
-
3rdparty/stout/Makefile.am 2d27da7e6
Diff: https://reviews.apache.org/r/54951/diff/
Testing
---
Build all of Mesos from source.
Thanks,
Aaron Wood
1 - 100 of 204 matches
Mail list logo
