---
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
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
; 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
et? 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
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/#review
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
lso, I'm assuming 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.org/r/60546/#review179581
---
accordingly.
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
--
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60280/#review179433
---
On June 22, 2017, 3:20 p.m., Aaron Wood wrote:
>
>
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
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
not been sent
to Mesos) to be 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/#review1
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 directory pathn
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());
> >
. 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.
orking_directory() << "': "
<< 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:
>
> -
x 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
66b-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
","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
t;
> > I 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
","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
utomatically 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
d13-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
iff: https://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
ze --disable-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
hat's 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://revi
-----
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
/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --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
iff: https://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
/bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
t 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
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
rg/r/59413/diff/2-3/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
-
This 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:
>
> --
3/diff/1-2/
Testing
---
`./bootstrap && mkdir build && cd build && ../configure --disable-python
--disable-java --disable-optimize --disable-hardening && make -j$(nproc)`
Thanks,
Aaron Wood
sable-optimize --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
individual 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
)
<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-m
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:
>
> --
rified 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
0/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 exposing the issue.
Thanks,
Aaron Wood
amework at it. Our framework is currently not generating v4
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
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
--
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:
>
>
UUIDs which was exposing the issue.
Thanks,
Aaron Wood
is fix
and pointing our framework at it. Our framework is currently not generating v4
UUIDs which was causing the issue.
Thanks,
Aaron Wood
Aaron 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/
> -
/slave/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
with the
posix_launcher).
`make check -j4` also passes with no errors.
Thanks,
Aaron Wood
with the
posix_launcher).
`make check -j4` also passes with no errors.
Thanks,
Aaron Wood
ply, visit:
https://reviews.apache.org/r/54996/#review160821
-------
On Jan. 4, 2017, 9:55 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically ge
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 m
-
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:
>
>
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 m
");
> > }
> >
> > return stack;
> > }
> > ```
> >
> > We can get rid of the `allocate` function. Once created, it's by
> > default allocated.
>
> Aaron Wood wrote:
> `address` and `siz
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 automat
> > ```
> > 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
e-mail. To reply, visit:
https://reviews.apache.org/r/54996/#review160464
---
On Jan. 4, 2017, 12:26 a.m., Aaron Wood wrote:
>
> ---
> This is an au
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
he.org/r/54996/#review160159
---
On Dec. 29, 2016, 7:03 p.m., Aaron Wood wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://re
).
Thanks,
Aaron Wood
posix_launcher).
Thanks,
Aaron Wood
piled 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
piled 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
piled 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
also 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.
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
1 - 100 of 207 matches
Mail list logo