[jira] [Updated] (MESOS-6567) Actively Scan for CNI Configurations

2016-12-21 Thread Jie Yu (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jie Yu updated MESOS-6567:
--
Shepherd: Jie Yu

> Actively Scan for CNI Configurations
> 
>
> Key: MESOS-6567
> URL: https://issues.apache.org/jira/browse/MESOS-6567
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Dan Osborne
>Assignee: Avinash Sridharan
> Fix For: 1.2.0
>
>
> Mesos-Agent currently loads the CNI configs into memory at startup. After 
> this point, new configurations that are added will remain unknown to the 
> Mesos Agent process until it is restarted.
> This ticket is to request that the Mesos Agent process can the CNI config 
> directory each time it is networking a task, so that modifying, adding, and 
> removing networks will not require a slave reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6831) Add metrics for `slave` libprocess' event queue

2016-12-21 Thread Zhitao Li (JIRA) 
Zhitao Li created MESOS-6831:


 Summary: Add metrics for `slave` libprocess' event queue
 Key: MESOS-6831
 URL: https://issues.apache.org/jira/browse/MESOS-6831
 Project: Mesos
  Issue Type: Improvement
  Components: agent
Reporter: Zhitao Li


We have event queue metrics for master and allocator in 
http://mesos.apache.org/documentation/latest/monitoring/, but we don't have the 
event queue length for the most important libprocess actor in agent `slave`.

I propose we add similar metrics to this actor. This is at least useful in 
debugging the issues of whether  Mesos agent is overloaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC

2016-12-21 Thread Aaron Wood (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aaron Wood updated MESOS-6830:
--
Description: 
Gold linker complains about using -pie without -fPIC:

/usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' 
can not be used when making a shared object; recompile with -fPIC
local/mesos_local-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
cli/mesos-mesos.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:5208: recipe for target 'mesos-local' failed
make[2]: *** [mesos-local] Error 1
make[2]: *** Waiting for unfinished jobs
/Makefile:5131: recipe for target 'mesos' failed
make[2]: *** [mesos] Error 1
usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not 
be used when making a shared object; recompile with -fPIC
log/mesos_log-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

https://reviews.apache.org/r/54953/

  was:
Gold linker complains about using -pie without -fPIC:

/usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' 
can not be used when making a shared object; recompile with -fPIC
local/mesos_local-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
cli/mesos-mesos.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:5208: recipe for target 'mesos-local' failed
make[2]: *** [mesos-local] Error 1
make[2]: *** Waiting for unfinished jobs
/Makefile:5131: recipe for target 'mesos' failed
make[2]: *** [mesos] Error 1
usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not 
be used when making a shared object; recompile with -fPIC
log/mesos_log-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status


> Mesos fails to link with gold when providing -pie without -fPIC
> ---
>
> Key: MESOS-6830
> URL: https://issues.apache.org/jira/browse/MESOS-6830
> Project: Mesos
>  Issue Type: Bug
>  Components: build, libprocess, security, stout
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> Gold linker complains about using -pie without -fPIC:
> /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against 
> `.rodata' can not be used when making a shared object; recompile with -fPIC
> local/mesos_local-main.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
> not be used when making a shared object; recompile with -fPIC
> cli/mesos-mesos.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:5208: recipe for target 'mesos-local' failed
> make[2]: *** [mesos-local] Error 1
> make[2]: *** Waiting for unfinished jobs
> /Makefile:5131: recipe for target 'mesos' failed
> make[2]: *** [mesos] Error 1
> usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can 
> not be used when making a shared object; recompile with -fPIC
> log/mesos_log-main.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> https://reviews.apache.org/r/54953/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-6826) OsTest.User fails on recent Arch Linux

2016-12-21 Thread Neil Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Conway reassigned MESOS-6826:
--

Assignee: Neil Conway

> OsTest.User fails on recent Arch Linux
> --
>
> Key: MESOS-6826
> URL: https://issues.apache.org/jira/browse/MESOS-6826
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] OsTest.User
> ../../../mesos/3rdparty/stout/tests/os_tests.cpp:683: Failure
> Value of: os::getuid(UUID::random().toString()).isNone()
>   Actual: false
> Expected: true
> ../../../mesos/3rdparty/stout/tests/os_tests.cpp:684: Failure
> Value of: os::getgid(UUID::random().toString()).isNone()
>   Actual: false
> Expected: true
> [  FAILED  ] OsTest.User (12 ms)
> {noformat}
> Appeared relatively recently (last two weeks). Cause appears to be that 
> {{getpwnam\_r}} now returns {{EINVAL}} for an invalid input, which 
> {{os::getuid()}} and {{os::getgid()}} are not prepared to handle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6829) Mesos fails to compile when using FORTIFY_SOURCE without optimizations

2016-12-21 Thread Aaron Wood (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aaron Wood updated MESOS-6829:
--
Description: 
Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE 
is used without optimizations enabled (see here for related information 
https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in 
some environments such as CentOS 7 and Arch Linux with GCC 6.2.

Probably one of the reasons why it didn't get caught earlier by CI:

"This #warning appears to be causing more grief than it is solving; for 
example, see this autoconf thread that complains that it is breaking configure 
scripts, and therefore Debian's decision to revert this patch in their build of 
glibc:

https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html
http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup;

https://reviews.apache.org/r/54949/
https://reviews.apache.org/r/54950/
https://reviews.apache.org/r/54951/

  was:
Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE 
is used without optimizations enabled (see here for related information 
https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in 
some environments such as CentOS 7 and Arch Linux with GCC 6.2.

Probably one of the reasons why it didn't get caught earlier by CI:

"This #warning appears to be causing more grief than it is solving; for 
example, see this autoconf thread that complains that it is breaking configure 
scripts, and therefore Debian's decision to revert this patch in their build of 
glibc:

https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html
http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup;


> Mesos fails to compile when using FORTIFY_SOURCE without optimizations
> --
>
> Key: MESOS-6829
> URL: https://issues.apache.org/jira/browse/MESOS-6829
> Project: Mesos
>  Issue Type: Bug
>  Components: build, libprocess, security, stout
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> Fome some versions of gcc/glibc a warning will be produced with 
> FORTIFY_SOURCE is used without optimizations enabled (see here for related 
> information https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only 
> happens in some environments such as CentOS 7 and Arch Linux with GCC 6.2.
> Probably one of the reasons why it didn't get caught earlier by CI:
> "This #warning appears to be causing more grief than it is solving; for 
> example, see this autoconf thread that complains that it is breaking 
> configure scripts, and therefore Debian's decision to revert this patch in 
> their build of glibc:
> https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html
> http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup;
> https://reviews.apache.org/r/54949/
> https://reviews.apache.org/r/54950/
> https://reviews.apache.org/r/54951/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6567) Actively Scan for CNI Configurations

2016-12-21 Thread Jie Yu (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768302#comment-15768302
 ] 

Jie Yu commented on MESOS-6567:
---

commit 58f180a2059fc7610ee2ff6b3f0991f9d5492212
Author: Avinash sridharan 
Date:   Wed Dec 21 11:42:11 2016 -0800

Modified the initialization logic for `network/cni` isolator.

Since the `network/cni` isolator will soon be able to
add/modify/delete CNI configuration files without the need for agent
restart, we are changing the initialization logic to not bail out if
we see errors while reading a CNI configuration file or don't find a
CNI  plugin for a given CNI configuration. If either of these errors
occur the `network/cni` isolator would simply skip the specific CNI
network and complete the initialization.

Review: https://reviews.apache.org/r/54716/

> Actively Scan for CNI Configurations
> 
>
> Key: MESOS-6567
> URL: https://issues.apache.org/jira/browse/MESOS-6567
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Dan Osborne
>Assignee: Avinash Sridharan
>
> Mesos-Agent currently loads the CNI configs into memory at startup. After 
> this point, new configurations that are added will remain unknown to the 
> Mesos Agent process until it is restarted.
> This ticket is to request that the Mesos Agent process can the CNI config 
> directory each time it is networking a task, so that modifying, adding, and 
> removing networks will not require a slave reboot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC

2016-12-21 Thread Aaron Wood (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aaron Wood updated MESOS-6830:
--
Description: 
Gold linker complains about using -pie without -fPIC:

/usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' 
can not be used when making a shared object; recompile with -fPIC
local/mesos_local-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
cli/mesos-mesos.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:5208: recipe for target 'mesos-local' failed
make[2]: *** [mesos-local] Error 1
make[2]: *** Waiting for unfinished jobs
/Makefile:5131: recipe for target 'mesos' failed
make[2]: *** [mesos] Error 1
usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not 
be used when making a shared object; recompile with -fPIC
log/mesos_log-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

  was:
Gold linker complains about using -pie without -fPIC:

/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos-log log/mesos_log-main.o libmesos.la -lz 
-lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos-local local/mesos_local-main.o libmesos.la -lz 
-lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos cli/mesos-mesos.o libmesos.la -lz -lsvn_delta-1 
-lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-local 
local/mesos_local-main.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-log 
log/mesos_log-main.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos 
cli/mesos-mesos.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
/usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' 
can not be used when making a shared object; recompile with -fPIC
local/mesos_local-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
cli/mesos-mesos.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:5208: recipe for target 'mesos-local' failed
make[2]: *** [mesos-local] Error 1
make[2]: *** Waiting for unfinished jobs
/Makefile:5131: recipe for target 'mesos' failed
make[2]: *** [mesos] Error 1
usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not 
be used when making a shared object; recompile with -fPIC
log/mesos_log-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status


> Mesos fails to link with gold when providing -pie without -fPIC
> ---
>
> Key: MESOS-6830
> URL: https://issues.apache.org/jira/browse/MESOS-6830
> Project: Mesos
>  Issue Type: Bug
>  Components: build, libprocess, security, stout
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> Gold linker complains about using -pie without -fPIC:
> /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against 
> `.rodata' can not be used when making a shared object; recompile with -fPIC
> local/mesos_local-main.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> /usr/bin/ld: cli/mesos-mesos.o: relocation

[jira] [Created] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC

2016-12-21 Thread Aaron Wood (JIRA) 
Aaron Wood created MESOS-6830:
-

 Summary: Mesos fails to link with gold when providing -pie without 
-fPIC
 Key: MESOS-6830
 URL: https://issues.apache.org/jira/browse/MESOS-6830
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess, security, stout
Reporter: Aaron Wood
Assignee: Aaron Wood


Gold linker complains about using -pie without -fPIC:

/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos-log log/mesos_log-main.o libmesos.la -lz 
-lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos-local local/mesos_local-main.o libmesos.la -lz 
-lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -pthread -Wall -Wsign-compare 
-Wformat-security  -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie 
-Wl,--as-needed  -o mesos cli/mesos-mesos.o libmesos.la -lz -lsvn_delta-1 
-lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz  -lrt
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-local 
local/mesos_local-main.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-log 
log/mesos_log-main.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 
-Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos 
cli/mesos-mesos.o  ./.libs/libmesos.so 
/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 
/usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so 
-lz -lrt -pthread
/usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' 
can not be used when making a shared object; recompile with -fPIC
local/mesos_local-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
cli/mesos-mesos.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:5208: recipe for target 'mesos-local' failed
make[2]: *** [mesos-local] Error 1
make[2]: *** Waiting for unfinished jobs
/Makefile:5131: recipe for target 'mesos' failed
make[2]: *** [mesos] Error 1
usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not 
be used when making a shared object; recompile with -fPIC
log/mesos_log-main.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6829) Mesos fails to compile when using FORTIFY_SOURCE without optimizations

2016-12-21 Thread Aaron Wood (JIRA) 
Aaron Wood created MESOS-6829:
-

 Summary: Mesos fails to compile when using FORTIFY_SOURCE without 
optimizations
 Key: MESOS-6829
 URL: https://issues.apache.org/jira/browse/MESOS-6829
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess, security, stout
Reporter: Aaron Wood
Assignee: Aaron Wood


Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE 
is used without optimizations enabled (see here for related information 
https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in 
some environments such as CentOS 7 and Arch Linux with GCC 6.2.

Probably one of the reasons why it didn't get caught earlier by CI:

"This #warning appears to be causing more grief than it is solving; for 
example, see this autoconf thread that complains that it is breaking configure 
scripts, and therefore Debian's decision to revert this patch in their build of 
glibc:

https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html
http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup;



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6828) Consider ways for frameworks to ignore offers with an Unavailability

2016-12-21 Thread Joris Van Remoortere (JIRA) 
Joris Van Remoortere created MESOS-6828:
---

 Summary: Consider ways for frameworks to ignore offers with an 
Unavailability
 Key: MESOS-6828
 URL: https://issues.apache.org/jira/browse/MESOS-6828
 Project: Mesos
  Issue Type: Improvement
Reporter: Joris Van Remoortere
Assignee: Artem Harutyunyan


Due to the opt-in nature of maintenance primitives in Mesos, there is a 
deficiency for cluster administrators when frameworks have not opted in.

An example case:
- Cluster with reasonable churn (tasks terminate naturally)
- Operator specifies maintenance schedule

Ideally *even* in a world where none of the frameworks had opted in to 
maintenance primitives the operator would have some way of preventing 
frameworks from scheduling further work on agents in the schedule. The natural 
termination of the tasks in the cluster would allow the nodes to drain 
gracefully and the operator to then perform maintenance.

2 options that have been discussed so far:
# Provide a capability for frameworks to automatically filter offers with an 
{{Unavailability}} set.
#* Pro: Finer grained control. Allows other frameworks to keep scheduling short 
lived tasks that can complete before the Unavailability.
#* Con: All frameworks have to be updated. Consider making this an environment 
variable to the scheduler driver for legacy frameworks.
# Provide a flag on the master to filter all offers with an {{Unavailability}} 
set.
#* Pro: Immediately actionable / usable.
#* Con: Coarse grained. Some frameworks may suffer efficiency.
#* Con: *Dangerous*: planning out a multi-day maintenance schedule for an 
entire cluster will prevent any frameworks from scheduling further work, 
potentially stalling the cluster.

Action Items: Provide further context for each option and consider others. We 
need to ensure we have something immediately consumable by users to fill the 
gap until maintenance primitives are the norm. We also need to ensure we 
prevent dangerous scenarios like the Con listed for option #2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6827) Fix the order in which "self.hpp" is included in "self.cpp".

2016-12-21 Thread Alexander Rukletsov (JIRA) 
Alexander Rukletsov created MESOS-6827:
--

 Summary: Fix the order in which "self.hpp" is included in 
"self.cpp".
 Key: MESOS-6827
 URL: https://issues.apache.org/jira/browse/MESOS-6827
 Project: Mesos
  Issue Type: Improvement
Reporter: Alexander Rukletsov
Priority: Minor


According to our 
[styleguide|https://github.com/apache/mesos/blob/master/docs/c%2B%2B-style-guide.md#order-of-includes],
 each {{.cpp}} file should include the related {{.hpp}} first to ensure that a 
header file always includes all symbols it requires. However, our codebase does 
not follow this rule strictly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-6320) Implement clang-tidy check to catch incorrect flags hierarchies

2016-12-21 Thread Benjamin Bannier (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bannier reassigned MESOS-6320:
---

Assignee: Benjamin Bannier

> Implement clang-tidy check to catch incorrect flags hierarchies
> ---
>
> Key: MESOS-6320
> URL: https://issues.apache.org/jira/browse/MESOS-6320
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: clang-tidy, mesosphere
>
> Classes need to always use {{virtual}} inheritance when being derived from 
> {{FlagsBase}}. Also, in order to compose such derived flags they should be 
> inherited virtually again.
> Some examples:
> {code}
> struct A : virtual FlagsBase {}; // OK
> struct B : FlagsBase {}; // ERROR
> struct C : A {}; // ERROR
> {code}
> We should implement a clang-tidy checker to catch such wrong inheritance 
> issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5387) mesos-execute exit status is always success

2016-12-21 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767620#comment-15767620
 ] 

Vinod Kone commented on MESOS-5387:
---

Thanks [~ror6ax] for volunteering to fix. The next step is to find a shepherd. 
[~gyliu] or [~qianzhang] is this something you can shepherd?

> mesos-execute exit status is always success
> ---
>
> Key: MESOS-5387
> URL: https://issues.apache.org/jira/browse/MESOS-5387
> Project: Mesos
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.28.1
>Reporter: Luca Bruno
>
> mesos-execute should be able to return an exit status based on the status of 
> the task. Currently it always exists with 0.
> It's very hard for a caller to know the status of the task, for example from 
> a bash script calling mesos-execute.
> I believe mesos-execute is a simple but very useful cli tool for one-shot 
> tasks, and as such deserves more attention.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6826) OsTest.User fails on recent Arch Linux

2016-12-21 Thread Neil Conway (JIRA) 
Neil Conway created MESOS-6826:
--

 Summary: OsTest.User fails on recent Arch Linux
 Key: MESOS-6826
 URL: https://issues.apache.org/jira/browse/MESOS-6826
 Project: Mesos
  Issue Type: Bug
  Components: stout
Reporter: Neil Conway


{noformat}
[ RUN  ] OsTest.User
../../../mesos/3rdparty/stout/tests/os_tests.cpp:683: Failure
Value of: os::getuid(UUID::random().toString()).isNone()
  Actual: false
Expected: true
../../../mesos/3rdparty/stout/tests/os_tests.cpp:684: Failure
Value of: os::getgid(UUID::random().toString()).isNone()
  Actual: false
Expected: true
[  FAILED  ] OsTest.User (12 ms)
{noformat}

Appeared relatively recently (last two weeks). Cause appears to be that 
{{getpwnam\_r}} now returns {{EINVAL}} for an invalid input, which 
{{os::getuid()}} and {{os::getgid()}} are not prepared to handle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-6825) Increase default allocation_interval for tests

2016-12-21 Thread Anand Mazumdar (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767510#comment-15767510
 ] 

Anand Mazumdar edited comment on MESOS-6825 at 12/21/16 4:54 PM:
-

> This means that if the host running the tests is slow, a test case might 
> receive a resource offer that it doesn't receive when running on a faster 
> host.

Did you mean that if the "task" in question in the test reaches a terminal 
state? This shouldn't happen otherwise if the "used" resources on the agent did 
not change (task is active)


was (Author: anandmazumdar):
> This means that if the host running the tests is slow, a test case might 
> receive a resource offer that it doesn't receive when running on a faster 
> host.

Did you mean that if the "task" in question in the test finishes? This 
shouldn't happen otherwise if the "used" resources on the agent did not change 
(task is active)

> Increase default allocation_interval for tests
> --
>
> Key: MESOS-6825
> URL: https://issues.apache.org/jira/browse/MESOS-6825
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> The default {{allocation_interval}} is 1 second. This means that if the host 
> running the tests is slow, a test case might receive a resource offer that it 
> doesn't receive when running on a faster host. We could workaround this by 
> explicitly using {{WillRepeatedly(Return())}}, but that is a bit kludgy and 
> obscures the intent of the test.
> One way to avoid this would be to pause the clock by default in tests 
> (MESOS-4101). That would be a quite involved change, however.
> Instead, we could consider raising the default {{allocation_interval}} to a 
> large value, such as 1 minute or longer. This would significantly reduce the 
> chance of host performance causing test flakiness. Moreover, it would help to 
> highlight tests that rely on real-time batch allocations for correctness: 
> generally tests should avoid doing this (because it causes test slowness). 
> They should instead pause the clock and then advance it by 
> {{allocation_interval}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5387) mesos-execute exit status is always success

2016-12-21 Thread Gregory Reshetniak (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767517#comment-15767517
 ] 

Gregory Reshetniak commented on MESOS-5387:
---

I'd like to take this task.
My first one in Mesos project, please let me know if I need to do anything else 
except for replying in here.
Thanks,
Greg

> mesos-execute exit status is always success
> ---
>
> Key: MESOS-5387
> URL: https://issues.apache.org/jira/browse/MESOS-5387
> Project: Mesos
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.28.1
>Reporter: Luca Bruno
>
> mesos-execute should be able to return an exit status based on the status of 
> the task. Currently it always exists with 0.
> It's very hard for a caller to know the status of the task, for example from 
> a bash script calling mesos-execute.
> I believe mesos-execute is a simple but very useful cli tool for one-shot 
> tasks, and as such deserves more attention.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6825) Increase default allocation_interval for tests

2016-12-21 Thread Anand Mazumdar (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767510#comment-15767510
 ] 

Anand Mazumdar commented on MESOS-6825:
---

> This means that if the host running the tests is slow, a test case might 
> receive a resource offer that it doesn't receive when running on a faster 
> host.

Did you mean that if the "task" in question in the test finishes? This 
shouldn't happen otherwise if the "used" resources on the agent did not change 
(task is active)

> Increase default allocation_interval for tests
> --
>
> Key: MESOS-6825
> URL: https://issues.apache.org/jira/browse/MESOS-6825
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> The default {{allocation_interval}} is 1 second. This means that if the host 
> running the tests is slow, a test case might receive a resource offer that it 
> doesn't receive when running on a faster host. We could workaround this by 
> explicitly using {{WillRepeatedly(Return())}}, but that is a bit kludgy and 
> obscures the intent of the test.
> One way to avoid this would be to pause the clock by default in tests 
> (MESOS-4101). That would be a quite involved change, however.
> Instead, we could consider raising the default {{allocation_interval}} to a 
> large value, such as 1 minute or longer. This would significantly reduce the 
> chance of host performance causing test flakiness. Moreover, it would help to 
> highlight tests that rely on real-time batch allocations for correctness: 
> generally tests should avoid doing this (because it causes test slowness). 
> They should instead pause the clock and then advance it by 
> {{allocation_interval}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6825) Increase default allocation_interval for tests

2016-12-21 Thread Neil Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Conway updated MESOS-6825:
---
Description: 
The default {{allocation_interval}} is 1 second. This means that if the host 
running the tests is slow, a test case might receive a resource offer that it 
doesn't receive when running on a faster host. We could workaround this by 
explicitly using {{WillRepeatedly(Return())}}, but that is a bit kludgy and 
obscures the intent of the test.

One way to avoid this would be to pause the clock by default in tests 
(MESOS-4101). That would be a quite involved change, however.

Instead, we could consider raising the default {{allocation_interval}} to a 
large value, such as 1 minute or longer. This would significantly reduce the 
chance of host performance causing test flakiness. Moreover, it would help to 
highlight tests that rely on real-time batch allocations for correctness: 
generally tests should avoid doing this (because it causes test slowness). They 
should instead pause the clock and then advance it by {{allocation_interval}}.

  was:
The default {{allocation_interval}} is 1 second. This means that if the host 
running the tests is slow, a test case might receive a resource offer that it 
doesn't receive when running on a faster host. We could workaround this by 
explicitly using {{WillRepeatedly(Return())}, but that is a bit kludgy and 
obscures the intent of the test.

One way to avoid this would be to pause the clock by default in tests 
(MESOS-4101). That would be a quite involved change, however.

Instead, we could consider raising the default {{allocation_interval}} to a 
large value, such as 1 minute or longer. This would significantly reduce the 
chance of host performance causing test flakiness. Moreover, it would help to 
highlight tests that rely on real-time batch allocations for correctness: 
generally tests should avoid doing this (because it causes test slowness). They 
should instead pause the clock and then advance it by {{allocation_interval}}.


> Increase default allocation_interval for tests
> --
>
> Key: MESOS-6825
> URL: https://issues.apache.org/jira/browse/MESOS-6825
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> The default {{allocation_interval}} is 1 second. This means that if the host 
> running the tests is slow, a test case might receive a resource offer that it 
> doesn't receive when running on a faster host. We could workaround this by 
> explicitly using {{WillRepeatedly(Return())}}, but that is a bit kludgy and 
> obscures the intent of the test.
> One way to avoid this would be to pause the clock by default in tests 
> (MESOS-4101). That would be a quite involved change, however.
> Instead, we could consider raising the default {{allocation_interval}} to a 
> large value, such as 1 minute or longer. This would significantly reduce the 
> chance of host performance causing test flakiness. Moreover, it would help to 
> highlight tests that rely on real-time batch allocations for correctness: 
> generally tests should avoid doing this (because it causes test slowness). 
> They should instead pause the clock and then advance it by 
> {{allocation_interval}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6825) Increase default allocation_interval for tests

2016-12-21 Thread Neil Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Conway updated MESOS-6825:
---
Description: 
The default {{allocation_interval}} is 1 second. This means that if the host 
running the tests is slow, a test case might receive a resource offer that it 
doesn't receive when running on a faster host. We could workaround this by 
explicitly using {{WillRepeatedly(Return())}, but that is a bit kludgy and 
obscures the intent of the test.

One way to avoid this would be to pause the clock by default in tests 
(MESOS-4101). That would be a quite involved change, however.

Instead, we could consider raising the default {{allocation_interval}} to a 
large value, such as 1 minute or longer. This would significantly reduce the 
chance of host performance causing test flakiness. Moreover, it would help to 
highlight tests that rely on real-time batch allocations for correctness: 
generally tests should avoid doing this (because it causes test slowness). They 
should instead pause the clock and then advance it by {{allocation_interval}}.

  was:
The default {{allocation_interval}} is 1 second. This means that if the host 
running the tests is slow, a test case might receive a resource offer that it 
doesn't receive when running on a faster host. We could workaround this by 
explicitly using {{WillRepeatedly(Return())}, but that is a bit kludgy and 
obscures the intent of the test.

Instead, we could consider raising the default {{allocation_interval}} to a 
large value, such as 1 minute or longer. This would significantly reduce the 
chance of host performance causing test flakiness. Moreover, it would help to 
highlight tests that rely on real-time batch allocations for correctness: 
generally tests should avoid doing this (because it causes test slowness). They 
should instead pause the clock and then advance it by {{allocation_interval}}.


> Increase default allocation_interval for tests
> --
>
> Key: MESOS-6825
> URL: https://issues.apache.org/jira/browse/MESOS-6825
> Project: Mesos
>  Issue Type: Improvement
>  Components: tests
>Reporter: Neil Conway
>  Labels: mesosphere
>
> The default {{allocation_interval}} is 1 second. This means that if the host 
> running the tests is slow, a test case might receive a resource offer that it 
> doesn't receive when running on a faster host. We could workaround this by 
> explicitly using {{WillRepeatedly(Return())}, but that is a bit kludgy and 
> obscures the intent of the test.
> One way to avoid this would be to pause the clock by default in tests 
> (MESOS-4101). That would be a quite involved change, however.
> Instead, we could consider raising the default {{allocation_interval}} to a 
> large value, such as 1 minute or longer. This would significantly reduce the 
> chance of host performance causing test flakiness. Moreover, it would help to 
> highlight tests that rely on real-time batch allocations for correctness: 
> generally tests should avoid doing this (because it causes test slowness). 
> They should instead pause the clock and then advance it by 
> {{allocation_interval}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6825) Increase default allocation_interval for tests

2016-12-21 Thread Neil Conway (JIRA) 
Neil Conway created MESOS-6825:
--

 Summary: Increase default allocation_interval for tests
 Key: MESOS-6825
 URL: https://issues.apache.org/jira/browse/MESOS-6825
 Project: Mesos
  Issue Type: Improvement
  Components: tests
Reporter: Neil Conway


The default {{allocation_interval}} is 1 second. This means that if the host 
running the tests is slow, a test case might receive a resource offer that it 
doesn't receive when running on a faster host. We could workaround this by 
explicitly using {{WillRepeatedly(Return())}, but that is a bit kludgy and 
obscures the intent of the test.

Instead, we could consider raising the default {{allocation_interval}} to a 
large value, such as 1 minute or longer. This would significantly reduce the 
chance of host performance causing test flakiness. Moreover, it would help to 
highlight tests that rely on real-time batch allocations for correctness: 
generally tests should avoid doing this (because it causes test slowness). They 
should instead pause the clock and then advance it by {{allocation_interval}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6824) mesos-this-capture clang-tidy check has false positives

2016-12-21 Thread Benjamin Bannier (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767396#comment-15767396
 ] 

Benjamin Bannier commented on MESOS-6824:
-

[~mcypark], could you help with this?

> mesos-this-capture clang-tidy check has false positives
> ---
>
> Key: MESOS-6824
> URL: https://issues.apache.org/jira/browse/MESOS-6824
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: clang-tidy
>
> The {{mesos-this-capture}} clang-tidy checks incorrectly triggers on the code 
> here,
>   
> https://github.com/apache/mesos/blob/d2117362349ab4c383045720f77d42b2d9fd6871/src/slave/containerizer/mesos/io/switchboard.cpp#L1487
> We should tighten the matcher to avoid triggering on such constructs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-6824) mesos-this-capture clang-tidy check has false positives

2016-12-21 Thread Benjamin Bannier (JIRA) 
Benjamin Bannier created MESOS-6824:
---

 Summary: mesos-this-capture clang-tidy check has false positives
 Key: MESOS-6824
 URL: https://issues.apache.org/jira/browse/MESOS-6824
 Project: Mesos
  Issue Type: Bug
Reporter: Benjamin Bannier
Assignee: Benjamin Bannier


The {{mesos-this-capture}} clang-tidy checks incorrectly triggers on the code 
here,

  
https://github.com/apache/mesos/blob/d2117362349ab4c383045720f77d42b2d9fd6871/src/slave/containerizer/mesos/io/switchboard.cpp#L1487

We should tighten the matcher to avoid triggering on such constructs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6821) Override of automatic resources should be by exact match not substring

2016-12-21 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767339#comment-15767339
 ] 

Vinod Kone commented on MESOS-6821:
---

[~bmerry] Is this something you want to contribute a patch to? If so, I'll be 
happy to shepherd.

> Override of automatic resources should be by exact match not substring
> --
>
> Key: MESOS-6821
> URL: https://issues.apache.org/jira/browse/MESOS-6821
> Project: Mesos
>  Issue Type: Improvement
>  Components: agent
>Affects Versions: 1.1.0
> Environment: Ubuntu 16.04 x86_64
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: newbie
>
> The agent code for auto-detecting resources (cpus, mem, disk) assumes that, 
> say, "cpus" has been specified in the string "cpus" appears anywhere in the 
> resource string (see 
> [here](https://github.com/apache/mesos/blob/1.1.0/src/slave/containerizer/containerizer.cpp#L79)).
>  This means that using a custom resource called, say, "members", will disable 
> auto-detection of the "mem" resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6821) Override of automatic resources should be by exact match not substring

2016-12-21 Thread Vinod Kone (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-6821:
--
Labels: newbie  (was: )

> Override of automatic resources should be by exact match not substring
> --
>
> Key: MESOS-6821
> URL: https://issues.apache.org/jira/browse/MESOS-6821
> Project: Mesos
>  Issue Type: Improvement
>  Components: agent
>Affects Versions: 1.1.0
> Environment: Ubuntu 16.04 x86_64
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: newbie
>
> The agent code for auto-detecting resources (cpus, mem, disk) assumes that, 
> say, "cpus" has been specified in the string "cpus" appears anywhere in the 
> resource string (see 
> [here](https://github.com/apache/mesos/blob/1.1.0/src/slave/containerizer/containerizer.cpp#L79)).
>  This means that using a custom resource called, say, "members", will disable 
> auto-detection of the "mem" resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6819) HTTP API link is broken in Framework Development Guide

2016-12-21 Thread Vinod Kone (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-6819:
--
Component/s: documentation

>  HTTP API link is broken in Framework Development Guide
> ---
>
> Key: MESOS-6819
> URL: https://issues.apache.org/jira/browse/MESOS-6819
> Project: Mesos
>  Issue Type: Bug
>  Components: documentation
>Reporter: haosdent
>Priority: Minor
>  Labels: newbie
>
> In 
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/ 
> , the link to HTTP API is broken.
> {quote}
> If you are writing a scheduler against Mesos 1.0 or newer, it is recommended 
> to use the new HTTP API to talk to Mesos.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6819) HTTP API link is broken in Framework Development Guide

2016-12-21 Thread Vinod Kone (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-6819:
--
Labels: newbie  (was: )

>  HTTP API link is broken in Framework Development Guide
> ---
>
> Key: MESOS-6819
> URL: https://issues.apache.org/jira/browse/MESOS-6819
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>Priority: Minor
>  Labels: newbie
>
> In 
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/ 
> , the link to HTTP API is broken.
> {quote}
> If you are writing a scheduler against Mesos 1.0 or newer, it is recommended 
> to use the new HTTP API to talk to Mesos.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6813) IOSwitchboardServerTest.AttachOutput has stack overflow issue.

2016-12-21 Thread Vinod Kone (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767327#comment-15767327
 ] 

Vinod Kone commented on MESOS-6813:
---

[~jieyu] do we know the root cause for thi?

> IOSwitchboardServerTest.AttachOutput has stack overflow issue.
> --
>
> Key: MESOS-6813
> URL: https://issues.apache.org/jira/browse/MESOS-6813
> Project: Mesos
>  Issue Type: Bug
>Reporter: Jie Yu
>
> {noformat}
> bin/lldb-mesos-tests.sh --gtest_filter=IOSwitchboardServerTest.AttachOutput 
> --verbose
> 
> (lldb) run
> ...
> frame #3543: 0x000106a35cbd libmesos-1.2.0.dylib`bool 
> process::Future::_set(short&&) + 445
> frame #3544: 0x000106a35af5 
> libmesos-1.2.0.dylib`process::Future::set(short&&) + 37
> frame #3545: 0x000106a35ab0 libmesos-1.2.0.dylib`bool 
> process::Promise::_set(short&&) + 80
> frame #3546: 0x000106a33285 
> libmesos-1.2.0.dylib`process::Promise::set(short&&) + 37
> frame #3547: 0x000106a3322e 
> libmesos-1.2.0.dylib`process::polled(ev_loop*, ev_io*, int) + 110
> frame #3548: 0x000106abea59 
> libmesos-1.2.0.dylib`ev_invoke_pending(loop=) + 105 at ev.c:3288 
> [opt]
> frame #3549: 0x000106abf342 
> libmesos-1.2.0.dylib`ev_run(loop=, flags=) + 2242 
> at ev.c:3688 [opt]
> frame #3550: 0x000106a2ac5b libmesos-1.2.0.dylib`ev_loop(ev_loop*, 
> int) + 27
> frame #3551: 0x000106a2abc6 
> libmesos-1.2.0.dylib`process::EventLoop::run() + 134
> frame #3552: 0x00010698eff6 libmesos-1.2.0.dylib`void* 
> std::__1::__thread_proxy(void*) + 390
> frame #3553: 0x7fffd6ddbaab libsystem_pthread.dylib`_pthread_body + 
> 180
> frame #3554: 0x7fffd6ddb9f7 libsystem_pthread.dylib`_pthread_start + 
> 286
> frame #3555: 0x7fffd6ddb221 libsystem_pthread.dylib`thread_start + 13
> (lldb) quit
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6679) Allow `network/cni` isolator to dynamically load CNI configuration

2016-12-21 Thread Avinash Sridharan (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767293#comment-15767293
 ] 

Avinash Sridharan commented on MESOS-6679:
--

I marked this as a duplicate of MESOS-6567. We have reviews out for MESOS-6567, 
hope to land it this week some time.

> Allow `network/cni` isolator to dynamically load CNI configuration
> --
>
> Key: MESOS-6679
> URL: https://issues.apache.org/jira/browse/MESOS-6679
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> Currently the `network/cni` isolator learns the CNI config at startup. In 
> case the CNI config changes after the agent has started, the agent needs to 
> be restarted in order to learn any modifications to the CNI config.
> We would like the `network/cni` isolator to be able to load CNI config on the 
> fly without a restart. To achieve this we plan to introduce a new endpoint on 
> the `network/cni` isolator that would allow the operator to explicitly ask 
> the `network/cni` isolator to reload the configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6679) Allow `network/cni` isolator to dynamically load CNI configuration

2016-12-21 Thread Dan Osborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767272#comment-15767272
 ] 

Dan Osborne commented on MESOS-6679:


Resolved? Is there a link to the changes? Can we close the dupe 6567?

> Allow `network/cni` isolator to dynamically load CNI configuration
> --
>
> Key: MESOS-6679
> URL: https://issues.apache.org/jira/browse/MESOS-6679
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> Currently the `network/cni` isolator learns the CNI config at startup. In 
> case the CNI config changes after the agent has started, the agent needs to 
> be restarted in order to learn any modifications to the CNI config.
> We would like the `network/cni` isolator to be able to load CNI config on the 
> fly without a restart. To achieve this we plan to introduce a new endpoint on 
> the `network/cni` isolator that would allow the operator to explicitly ask 
> the `network/cni` isolator to reload the configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)