[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607755#comment-14607755 ] Tony Reix commented on MESOS-2216: -- Hi Jihun Your welcome ! Please have a look at the latest version of Mesos and the IBM JVM. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2959) Mesos website deploy script should include Javadoc for generated code.
[ https://issues.apache.org/jira/browse/MESOS-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2959: -- Labels: java javadoc mesosphere newbie ruby (was: ) > Mesos website deploy script should include Javadoc for generated code. > -- > > Key: MESOS-2959 > URL: https://issues.apache.org/jira/browse/MESOS-2959 > Project: Mesos > Issue Type: Improvement > Components: project website >Reporter: Connor Doyle > Labels: java, javadoc, mesosphere, newbie, ruby > > cc [~adam-mesos] and [~BenWhitehead] > Now that the Javadoc HTML includes the generated (protobuf and > autoconf-templated) classes, they should be included on the web site. The > rake file currently rolls its own call to the javadoc tool. > See: https://reviews.apache.org/r/35961 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607957#comment-14607957 ] Jihun Kang commented on MESOS-2216: --- Configuration script fixed and worked well with modified one. However, I found a segmentation fault when running test cases, and I will create another jira issue to handle this segmentation fault. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2936) Create a design document for Quota support in Master
[ https://issues.apache.org/jira/browse/MESOS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-2936: --- Story Points: 8 > Create a design document for Quota support in Master > > > Key: MESOS-2936 > URL: https://issues.apache.org/jira/browse/MESOS-2936 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Alexander Rukletsov >Assignee: Alexander Rukletsov > Labels: mesosphere > > Create a design document for the Quota feature support in Mesos Master > (excluding allocator) to be shared with the Mesos community. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2860) Create the basic infrastructure to handle /call endpoint
[
https://issues.apache.org/jira/browse/MESOS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607993#comment-14607993
]
Isabel Jimenez edited comment on MESOS-2860 at 6/30/15 9:09 AM:
https://reviews.apache.org/r/36037/
https://reviews.apache.org/r/36040/
https://reviews.apache.org/r/35934/
https://reviews.apache.org/r/35939/
was (Author: ijimenez):
https://reviews.apache.org/r/36037/
https://reviews.apache.org/r/36040/
https://reviews.apache.org/r/35934/
> Create the basic infrastructure to handle /call endpoint
>
>
> Key: MESOS-2860
> URL: https://issues.apache.org/jira/browse/MESOS-2860
> Project: Mesos
> Issue Type: Story
> Components: master
>Reporter: Marco Massenzio
>Assignee: Isabel Jimenez
> Labels: mesosphere
>
> This is the first basic step in ensuring the basic {{/call}} functionality:
> processing a
> {noformat}
> POST /call
> {noformat}
> and returning:
> - {{202}} if all goes well;
> - {{401}} if not authorized; and
> - {{403}} if the request is malformed.
> We'll get more sophisticated as the work progressed (eg, supporting {{415}}
> if the content-type is not of the right kind).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2860) Create the basic infrastructure to handle /call endpoint
[
https://issues.apache.org/jira/browse/MESOS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607993#comment-14607993
]
Isabel Jimenez edited comment on MESOS-2860 at 6/30/15 9:08 AM:
https://reviews.apache.org/r/36037/
https://reviews.apache.org/r/36040/
https://reviews.apache.org/r/35934/
was (Author: ijimenez):
https://reviews.apache.org/r/36037/
> Create the basic infrastructure to handle /call endpoint
>
>
> Key: MESOS-2860
> URL: https://issues.apache.org/jira/browse/MESOS-2860
> Project: Mesos
> Issue Type: Story
> Components: master
>Reporter: Marco Massenzio
>Assignee: Isabel Jimenez
> Labels: mesosphere
>
> This is the first basic step in ensuring the basic {{/call}} functionality:
> processing a
> {noformat}
> POST /call
> {noformat}
> and returning:
> - {{202}} if all goes well;
> - {{401}} if not authorized; and
> - {{403}} if the request is malformed.
> We'll get more sophisticated as the work progressed (eg, supporting {{415}}
> if the content-type is not of the right kind).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607998#comment-14607998 ] Jihun Kang commented on MESOS-2216: --- I created a [review request|https://reviews.apache.org/r/36041/]. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608022#comment-14608022 ] Tony Reix commented on MESOS-2216: -- A segmentation fault with IBM JVM ? I am interested. Can you provide me with the changes you made so that I can try to reproduce the issue in my environment ? Moreover, I do not think that IBM manages the crashes of their JVM by means of JIRAs. They rather use what they call "PMR". Thanks ! > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2960) Configure DiscoveryInfo and Visibility per port
Frank Scholten created MESOS-2960: - Summary: Configure DiscoveryInfo and Visibility per port Key: MESOS-2960 URL: https://issues.apache.org/jira/browse/MESOS-2960 Project: Mesos Issue Type: Improvement Components: general Affects Versions: 0.22.1 Reporter: Frank Scholten Fix For: 0.24.0 For Mesos Elasticsearch I like to use DiscoveryInfo to advertise the client port (9200) with Visibility=EXTERNAL so it can be discovered by load balancers while advertising the transport port (9300) as Visibility=FRAMEWORK because it is used by nodes to talk too each other and should not be load balanced. However, I can only set one DiscoveryInfo and one visibility, instead of one per port. I suggest to allow multiple DiscoveryInfo's to be configured with their own visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2960) Configure DiscoveryInfo and Visibility per port
[ https://issues.apache.org/jira/browse/MESOS-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2960: -- Labels: mesosphere (was: ) > Configure DiscoveryInfo and Visibility per port > --- > > Key: MESOS-2960 > URL: https://issues.apache.org/jira/browse/MESOS-2960 > Project: Mesos > Issue Type: Improvement > Components: general >Affects Versions: 0.22.1 >Reporter: Frank Scholten > Labels: mesosphere > Fix For: 0.24.0 > > > For Mesos Elasticsearch I like to use DiscoveryInfo to advertise the client > port (9200) with Visibility=EXTERNAL so it can be discovered by load > balancers while advertising the transport port (9300) as Visibility=FRAMEWORK > because it is used by nodes to talk too each other and should not be load > balanced. > However, I can only set one DiscoveryInfo and one visibility, instead of one > per port. I suggest to allow multiple DiscoveryInfo's to be configured with > their own visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2487) Ensure protobuf "==" operator does not go out of sync with new protobuf fields
[ https://issues.apache.org/jira/browse/MESOS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608096#comment-14608096 ] Frank Scholten commented on MESOS-2487: --- I just filed https://issues.apache.org/jira/browse/MESOS-2960, started looking at the code and saw this issue mentioned in type_utils.cpp I'm quite new to the Mesos code base so I might overlook things but perhaps custom protobuf options be used to designate essential values for equality checks? > Ensure protobuf "==" operator does not go out of sync with new protobuf fields > -- > > Key: MESOS-2487 > URL: https://issues.apache.org/jira/browse/MESOS-2487 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone > > Currently when a new field is added to a protobuf that has a custom "==" > operator defined, we don't make sure that the field is accounted for in the > comparison. Ideally we should catch such errors at build time or 'make check' > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608168#comment-14608168 ] Jihun Kang commented on MESOS-2216: --- You can download diff file from my review request. I did not look at this segmentation fault error yet, so I don't have any idea which one needs to fix. I found out some test cases worked well, but one of them did not. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608252#comment-14608252 ] Tony Reix commented on MESOS-2216: -- I've got the patch. Thanks. I'll try on my side asap. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2119) Add Socket tests
[ https://issues.apache.org/jira/browse/MESOS-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608353#comment-14608353 ] Benjamin Hindman commented on MESOS-2119: - I moved this to 0.24.0 for now. > Add Socket tests > > > Key: MESOS-2119 > URL: https://issues.apache.org/jira/browse/MESOS-2119 > Project: Mesos > Issue Type: Task > Components: libprocess >Reporter: Niklas Quarfot Nielsen >Assignee: Joris Van Remoortere > Labels: mesosphere > > Add more Socket specific tests to get coverage while doing libev to libevent > (w and wo SSL) move -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2119) Add Socket tests
[ https://issues.apache.org/jira/browse/MESOS-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman updated MESOS-2119: Target Version/s: 0.24.0 (was: 0.23.0) > Add Socket tests > > > Key: MESOS-2119 > URL: https://issues.apache.org/jira/browse/MESOS-2119 > Project: Mesos > Issue Type: Task > Components: libprocess >Reporter: Niklas Quarfot Nielsen >Assignee: Joris Van Remoortere > Labels: mesosphere > > Add more Socket specific tests to get coverage while doing libev to libevent > (w and wo SSL) move -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2424) Components installed by Mesos 0.22.0-rc2 conflict with python-setuptools on CentOS 6
[
https://issues.apache.org/jira/browse/MESOS-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608431#comment-14608431
]
ASF GitHub Bot commented on MESOS-2424:
---
GitHub user kamilchm opened a pull request:
https://github.com/apache/mesos/pull/49
MESOS-2424 FIX: protobuf installs latest setuptools in Mesos dist if …
…there's older one in build system OS
https://github.com/google/protobuf/blob/v2.5.0/python/setup.py#L187
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kamilchm/mesos no-setuptools-with-mesos-dist
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/mesos/pull/49.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #49
commit 6356d5ecdeab169407b07f8225c9e6f40ce86a7e
Author: Kamil Chmielewski
Date: 2015-06-30T15:03:52Z
MESOS-2424 FIX: protobuf installs latest setuptools in Mesos dist if
there's older one in build system OS
https://github.com/google/protobuf/blob/v2.5.0/python/setup.py#L187
> Components installed by Mesos 0.22.0-rc2 conflict with python-setuptools on
> CentOS 6
>
>
> Key: MESOS-2424
> URL: https://issues.apache.org/jira/browse/MESOS-2424
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.22.0
> Environment: Package Build Env: CentOS 6.5
> Test Env: CentOS 6.5 + python_setuptools + mesos 0.22.0-rc2 package
>Reporter: Jeremy Lingmann
>
> With Mesos 0.22.0-rc2 we are seeing files installed in /usr/lib/python2.6
> which conflict with the upstream python-setuptools package on CentOS 6. This
> is different behavior with 0.22.0 and something we were not seeing with
> 0.21.1 builds for CentOS 6.
> Here is the failure with our pre-built package:
> {code}
> # yum install ./pkg.rpm
> Loaded plugins: fastestmirror, presto
> Loading mirror speeds from cached hostfile
> * base: mirrors.advancedhosters.com
> * extras: mirror.ash.fastserv.com
> * updates: mirrors.lga7.us.voxel.net
> Setting up Install Process
> Examining ./pkg.rpm: mesos-0.22.0-0.1.20150228011042.rc2.centos65.x86_64
> Marking ./pkg.rpm to be installed
> Resolving Dependencies
> --> Running transaction check
> ---> Package mesos.x86_64 0:0.22.0-0.1.20150228011042.rc2.centos65 will be
> installed
> --> Processing Dependency: subversion for package:
> mesos-0.22.0-0.1.20150228011042.rc2.centos65.x86_64
> --> Running transaction check
> ---> Package subversion.x86_64 0:1.6.11-12.el6_6 will be installed
> --> Processing Dependency: perl(URI) >= 1.17 for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: apr >= 1.3.0 for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libneon.so.27()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libaprutil-1.so.0()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libapr-1.so.0()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Running transaction check
> ---> Package apr.x86_64 0:1.3.9-5.el6_2 will be installed
> ---> Package apr-util.x86_64 0:1.3.9-3.el6_0.1 will be installed
> ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be installed
> --> Processing Dependency: libproxy.so.0()(64bit) for package:
> neon-0.29.3-3.el6_4.x86_64
> --> Processing Dependency: libpakchois.so.0()(64bit) for package:
> neon-0.29.3-3.el6_4.x86_64
> ---> Package perl-URI.noarch 0:1.40-2.el6 will be installed
> --> Running transaction check
> ---> Package libproxy.x86_64 0:0.3.0-10.el6 will be installed
> --> Processing Dependency: libproxy-python = 0.3.0-10.el6 for package:
> libproxy-0.3.0-10.el6.x86_64
> --> Processing Dependency: libproxy-bin = 0.3.0-10.el6 for package:
> libproxy-0.3.0-10.el6.x86_64
> ---> Package pakchois.x86_64 0:0.4-3.2.el6 will be installed
> --> Running transaction check
> ---> Package libproxy-bin.x86_64 0:0.3.0-10.el6 will be installed
> ---> Package libproxy-python.x86_64 0:0.3.0-10.el6 will be installed
> --> Finished Dependency Resolution
> Dependencies Resolved
> ==
> Package Arch Version
> Repository
> Size
> ==
> Installing:
> mesos x86_64
> 0.22.0-0.1.20150228011042
[jira] [Commented] (MESOS-2424) Components installed by Mesos 0.22.0-rc2 conflict with python-setuptools on CentOS 6
[
https://issues.apache.org/jira/browse/MESOS-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608442#comment-14608442
]
Kamil Chmielewski commented on MESOS-2424:
--
Try to update system installed *setuptools* before you build Mesos. Protobuf
won't install it then.
See https://github.com/google/protobuf/blob/v2.5.0/python/setup.py#L187
> Components installed by Mesos 0.22.0-rc2 conflict with python-setuptools on
> CentOS 6
>
>
> Key: MESOS-2424
> URL: https://issues.apache.org/jira/browse/MESOS-2424
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.22.0
> Environment: Package Build Env: CentOS 6.5
> Test Env: CentOS 6.5 + python_setuptools + mesos 0.22.0-rc2 package
>Reporter: Jeremy Lingmann
>
> With Mesos 0.22.0-rc2 we are seeing files installed in /usr/lib/python2.6
> which conflict with the upstream python-setuptools package on CentOS 6. This
> is different behavior with 0.22.0 and something we were not seeing with
> 0.21.1 builds for CentOS 6.
> Here is the failure with our pre-built package:
> {code}
> # yum install ./pkg.rpm
> Loaded plugins: fastestmirror, presto
> Loading mirror speeds from cached hostfile
> * base: mirrors.advancedhosters.com
> * extras: mirror.ash.fastserv.com
> * updates: mirrors.lga7.us.voxel.net
> Setting up Install Process
> Examining ./pkg.rpm: mesos-0.22.0-0.1.20150228011042.rc2.centos65.x86_64
> Marking ./pkg.rpm to be installed
> Resolving Dependencies
> --> Running transaction check
> ---> Package mesos.x86_64 0:0.22.0-0.1.20150228011042.rc2.centos65 will be
> installed
> --> Processing Dependency: subversion for package:
> mesos-0.22.0-0.1.20150228011042.rc2.centos65.x86_64
> --> Running transaction check
> ---> Package subversion.x86_64 0:1.6.11-12.el6_6 will be installed
> --> Processing Dependency: perl(URI) >= 1.17 for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: apr >= 1.3.0 for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libneon.so.27()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libaprutil-1.so.0()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Processing Dependency: libapr-1.so.0()(64bit) for package:
> subversion-1.6.11-12.el6_6.x86_64
> --> Running transaction check
> ---> Package apr.x86_64 0:1.3.9-5.el6_2 will be installed
> ---> Package apr-util.x86_64 0:1.3.9-3.el6_0.1 will be installed
> ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be installed
> --> Processing Dependency: libproxy.so.0()(64bit) for package:
> neon-0.29.3-3.el6_4.x86_64
> --> Processing Dependency: libpakchois.so.0()(64bit) for package:
> neon-0.29.3-3.el6_4.x86_64
> ---> Package perl-URI.noarch 0:1.40-2.el6 will be installed
> --> Running transaction check
> ---> Package libproxy.x86_64 0:0.3.0-10.el6 will be installed
> --> Processing Dependency: libproxy-python = 0.3.0-10.el6 for package:
> libproxy-0.3.0-10.el6.x86_64
> --> Processing Dependency: libproxy-bin = 0.3.0-10.el6 for package:
> libproxy-0.3.0-10.el6.x86_64
> ---> Package pakchois.x86_64 0:0.4-3.2.el6 will be installed
> --> Running transaction check
> ---> Package libproxy-bin.x86_64 0:0.3.0-10.el6 will be installed
> ---> Package libproxy-python.x86_64 0:0.3.0-10.el6 will be installed
> --> Finished Dependency Resolution
> Dependencies Resolved
> ==
> Package Arch Version
> Repository
> Size
> ==
> Installing:
> mesos x86_64
> 0.22.0-0.1.20150228011042.rc2.centos65 /pkg
>67 M
> Installing for dependencies:
> apr x86_64 1.3.9-5.el6_2
> base123
> k
> apr-utilx86_64
> 1.3.9-3.el6_0.1 base
>87 k
> libproxyx86_64 0.3.0-10.el6
> base 39
> k
> libproxy-binx86_64 0.3.0-10.el6
> base9.0
> k
> libproxy-python x86_64
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608495#comment-14608495 ] Tony Reix commented on MESOS-2216: -- Hi The patch does not entirely apply for me: mesos-0.18.1$ patch -p1 < ../rb36041.patch patching file configure.ac Hunk #1 succeeded at 352 with fuzz 2 (offset -663 lines). Hunk #2 FAILED at 1025. 1 out of 2 hunks FAILED -- saving rejects to file configure.ac.rej I'm using Mesos 0.18.1 . Hummm Using now Mesos 0.22.1 , the ./configure works fine without the patch. Weird ? > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608532#comment-14608532 ] Tony Reix commented on MESOS-2216: -- Hummm Still with 0.22.1 . If I do: ./configure , that works, without the patch If I follow what I had noted (without or with the patch): ./bootstrap mkdir build cd build ../configure configure: error: failed to determine linker flags for using Java (bad JAVA_HOME or missing support for your architecture?) Hummm What are the actions for building Mesos that I must follow ? > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2961) Add cpuacct subsystem to cgroups
Jojy Varghese created MESOS-2961: Summary: Add cpuacct subsystem to cgroups Key: MESOS-2961 URL: https://issues.apache.org/jira/browse/MESOS-2961 Project: Mesos Issue Type: Task Components: containerization, docker, isolation Environment: linux Reporter: Jojy Varghese Assignee: Jojy Varghese Current cgroups implementation does not have a cpuacct subsystem implementation. This subsystem reports important metrics like user and system CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608686#comment-14608686 ] Jie Yu commented on MESOS-2961: --- MesosContainerizer already uses cpuacct subsystem. Are you referring to the docker containerizer? > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608713#comment-14608713 ] Jojy Varghese commented on MESOS-2961: -- I did not see a cpuaccct subsystem (namespace) implementation in cgroups.*pp. I needed it for docker case specifically but the generic implementation is missing. > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2961) Add cpuacct subsystem to cgroups
[
https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608749#comment-14608749
]
Ian Downes commented on MESOS-2961:
---
It gets created by default in the cgroups/cpushare isolator.
See {{src/slave/containerizer/isolators/cgroups/cpushare.cpp+91}}.
> Add cpuacct subsystem to cgroups
>
>
> Key: MESOS-2961
> URL: https://issues.apache.org/jira/browse/MESOS-2961
> Project: Mesos
> Issue Type: Task
> Components: containerization, docker, isolation
> Environment: linux
>Reporter: Jojy Varghese
>Assignee: Jojy Varghese
> Labels: containerizer, isolation
>
> Current cgroups implementation does not have a cpuacct subsystem
> implementation. This subsystem reports important metrics like user and system
> CPU ticks spent by a process.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608759#comment-14608759 ] Jojy Varghese commented on MESOS-2961: -- Ah. I was looking to use the cpuaact subsystem for docker containers. I am working on a patch that adds cpuaact subsystem (only stat) as I need it for docker and was hoping to have it for review by EOW. > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608807#comment-14608807 ] Jojy Varghese commented on MESOS-2961: -- On further going through tests am realizing that the stats information can be retrieved using cgroup::stat function. Its a bit hidden. Wondering if we can create a cgroups subsystem within mesos with functionality isolated per subsystem ? With a system view, we also achieve: - Modularity (reusable) - Add features like event notification which can then be broadcasted to listeners. WDYT? > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608807#comment-14608807 ] Jojy Varghese edited comment on MESOS-2961 at 6/30/15 6:30 PM: --- On further going through tests am realizing that the stats information can be retrieved using cgroup::stat function. Its a bit hidden. Wondering if we can create a cgroups subsystem within mesos with functionality isolated per subsystem ? With a system view, we also achieve: - Modularity (reusable) - Add features like event notification which can then be broadcasted to listeners. WDYT [~idownes] [~jieyu]? was (Author: jojy): On further going through tests am realizing that the stats information can be retrieved using cgroup::stat function. Its a bit hidden. Wondering if we can create a cgroups subsystem within mesos with functionality isolated per subsystem ? With a system view, we also achieve: - Modularity (reusable) - Add features like event notification which can then be broadcasted to listeners. WDYT? > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2962) Slave fails with Abort stacktrace when DNS cannot resolve hostname
Marco Massenzio created MESOS-2962:
--
Summary: Slave fails with Abort stacktrace when DNS cannot resolve
hostname
Key: MESOS-2962
URL: https://issues.apache.org/jira/browse/MESOS-2962
Project: Mesos
Issue Type: Bug
Components: slave
Affects Versions: 0.22.1
Reporter: Marco Massenzio
Assignee: Marco Massenzio
If the DNS cannot resolve the hostname-to-IP for a slave node, we correctly
return an {{Error}} object, but we then fail with a segfault.
This code adds a more user-friendly message and exits normally (with an
{{EXIT_FAILURE}} code).
For example, forcing {{net::getIp()}} to always return an {{Error}}, now causes
the slave to exit like this:
{noformat}
$ ./bin/mesos-slave.sh --master=10.10.1.121:5405
WARNING: Logging before InitGoogleLogging() is written to STDERR
E0630 11:31:45.777465 1944417024 process.cpp:899] Could not obtain the IP
address for stratos.local; the DNS service may not be able to resolve it: >>>
Marco was here!!!
$ echo $?
1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2963) Configure Jenkins to build ssl
Joris Van Remoortere created MESOS-2963: --- Summary: Configure Jenkins to build ssl Key: MESOS-2963 URL: https://issues.apache.org/jira/browse/MESOS-2963 Project: Mesos Issue Type: Improvement Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2897) Duplicate registration of Marathon & Chronos frameworks
[ https://issues.apache.org/jira/browse/MESOS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608880#comment-14608880 ] Aameek Singh commented on MESOS-2897: - Any update? > Duplicate registration of Marathon & Chronos frameworks > > > Key: MESOS-2897 > URL: https://issues.apache.org/jira/browse/MESOS-2897 > Project: Mesos > Issue Type: Bug > Components: framework >Affects Versions: 0.22.1 >Reporter: Aameek Singh > > Mesos: 0.22.1 > Built using Mesosphere distribution > Pointing to an external ZK cluster > For a prototype cluster, I often find duplicate registrations of frameworks, > i.e. the same framework is registered multiple times into Mesos. That often > duplicates the tasks running. > E.g. today, I see this: > IDHostUserNameActive TasksCPUsMem Max Share > Registered Re-Registered > …5050-1210-0002 sastm5-master-830a.watsonplatform.net root > chronos-2.3.3 0 0 0 B 0% 3 days ago - > …5050-1210-0001 sastm5-master-5006.watsonplatform.net root > chronos-2.3.3 0 0 0 B 0% 3 days ago - > …5050-1210- sastm5-master-830a.watsonplatform.net root > chronos-2.3.3 0 10 18.5 GB 90.238% a week ago - > …5050-1218-0002 sastm5-master-830a.watsonplatform.net root > marathon1 2 2.0 GB 16.667% 7 days ago 7 days ago > In this instance, chronos is registered 3 times, twice with the same master. > At other instances, I have seen marathon registered multiple times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2964) libprocess io does not support pick()
Artem Harutyunyan created MESOS-2964:
Summary: libprocess io does not support pick()
Key: MESOS-2964
URL: https://issues.apache.org/jira/browse/MESOS-2964
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Artem Harutyunyan
Priority: Minor
Finally, I so wish we could just do:
{code}
io::peek(request->socket, 6)
.then([request](const string& data) {
// Comment about the rules ...
if (data.length() < 2) { // Rule 1
} else if (...) { // Rule 2.
} else if (...) { // Rule 3.
}
if (ssl) {
accept_SSL_callback(request);
} else {
...;
}
});
{code}
from:
https://reviews.apache.org/r/31207/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2965) Stout os functions don't take stout::Path
Artem Harutyunyan created MESOS-2965:
Summary: Stout os functions don't take stout::Path
Key: MESOS-2965
URL: https://issues.apache.org/jira/browse/MESOS-2965
Project: Mesos
Issue Type: Improvement
Components: stout
Reporter: Artem Harutyunyan
Priority: Minor
For example:
{code}inline Try rm(const std::string& path){code} does not have an
overload for {code}inline Try rm(const Path& path){code}
The implementation should be something like:
{code}
inline Try rm(const Path& path)
{
rm(path.value);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Harutyunyan updated MESOS-2965:
-
Summary: Stout os functions don't take Path (was: Stout os functions
don't take stout::Path )
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2966) socket::peer() and socket::address() might fail with SSL enabled
Artem Harutyunyan created MESOS-2966: Summary: socket::peer() and socket::address() might fail with SSL enabled Key: MESOS-2966 URL: https://issues.apache.org/jira/browse/MESOS-2966 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Artem Harutyunyan Assignee: Joris Van Remoortere libevent SSL currently uses a secondary FD so we need to virtualize the get() function on socket interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2966) socket::peer() and socket::address() might fail with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-2966: - Fix Version/s: 0.23.0 > socket::peer() and socket::address() might fail with SSL enabled > > > Key: MESOS-2966 > URL: https://issues.apache.org/jira/browse/MESOS-2966 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Artem Harutyunyan >Assignee: Joris Van Remoortere > Labels: mesosphere > Fix For: 0.23.0 > > > libevent SSL currently uses a secondary FD so we need to virtualize the get() > function on socket interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2966) socket::peer() and socket::address() might fail with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-2966: - Sprint: Mesosphere Sprint 13 > socket::peer() and socket::address() might fail with SSL enabled > > > Key: MESOS-2966 > URL: https://issues.apache.org/jira/browse/MESOS-2966 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Artem Harutyunyan >Assignee: Joris Van Remoortere > Labels: mesosphere > Fix For: 0.23.0 > > > libevent SSL currently uses a secondary FD so we need to virtualize the get() > function on socket interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2967) Missing doxygen documentation for libprocess socket interface
Artem Harutyunyan created MESOS-2967: Summary: Missing doxygen documentation for libprocess socket interface Key: MESOS-2967 URL: https://issues.apache.org/jira/browse/MESOS-2967 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Artem Harutyunyan Convert existing comments to doxygen format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2964) libprocess io does not support peek()
[
https://issues.apache.org/jira/browse/MESOS-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Harutyunyan updated MESOS-2964:
-
Summary: libprocess io does not support peek() (was: libprocess io does
not support pick())
> libprocess io does not support peek()
> -
>
> Key: MESOS-2964
> URL: https://issues.apache.org/jira/browse/MESOS-2964
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie
>
> Finally, I so wish we could just do:
> {code}
> io::peek(request->socket, 6)
> .then([request](const string& data) {
> // Comment about the rules ...
> if (data.length() < 2) { // Rule 1
>
> } else if (...) { // Rule 2.
>
> } else if (...) { // Rule 3.
>
> }
>
> if (ssl) {
> accept_SSL_callback(request);
> } else {
> ...;
> }
> });
> {code}
> from:
> https://reviews.apache.org/r/31207/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2961) Add cpuacct subsystem to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-2961: - Description: Current cgroups implementation does not have a cpuacct subsystem implementation. This subsystem reports important metrics like user and system CPU ticks spent by a process. "cgroups" namespace has subsystem specific utilities for "cpu", "memory" etc. It could use other subsystems specific utils (eg. cpuacct). In the future, we could also view cgroups as a mesos-subsystem with features like event notifications. was:Current cgroups implementation does not have a cpuacct subsystem implementation. This subsystem reports important metrics like user and system CPU ticks spent by a process. > Add cpuacct subsystem to cgroups > > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. "cgroups" namespace has subsystem specific > utilities for "cpu", "memory" etc. It could use other subsystems specific > utils (eg. cpuacct). > In the future, we could also view cgroups as a mesos-subsystem with features > like event notifications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2961) Add cpuacct subsystem utils to cgroups
[ https://issues.apache.org/jira/browse/MESOS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-2961: - Summary: Add cpuacct subsystem utils to cgroups (was: Add cpuacct subsystem to cgroups) > Add cpuacct subsystem utils to cgroups > -- > > Key: MESOS-2961 > URL: https://issues.apache.org/jira/browse/MESOS-2961 > Project: Mesos > Issue Type: Task > Components: containerization, docker, isolation > Environment: linux >Reporter: Jojy Varghese >Assignee: Jojy Varghese > Labels: containerizer, isolation > > Current cgroups implementation does not have a cpuacct subsystem > implementation. This subsystem reports important metrics like user and system > CPU ticks spent by a process. "cgroups" namespace has subsystem specific > utilities for "cpu", "memory" etc. It could use other subsystems specific > utils (eg. cpuacct). > In the future, we could also view cgroups as a mesos-subsystem with features > like event notifications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Deleted] (MESOS-2872) Allow Libprocess processes to submit HTTP request/response to arbitrary URL
[ https://issues.apache.org/jira/browse/MESOS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen deleted MESOS-2872: > Allow Libprocess processes to submit HTTP request/response to arbitrary URL > --- > > Key: MESOS-2872 > URL: https://issues.apache.org/jira/browse/MESOS-2872 > Project: Mesos > Issue Type: Improvement >Reporter: Timothy Chen >Assignee: Timothy Chen > > Add support to issue a HTTP request to a arbitrary HTTP URL to the public > interface so that any libprocess process can submit a HTTP request and wait > on that response's future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2968) Implement Shared Copy backend
Timothy Chen created MESOS-2968: --- Summary: Implement Shared Copy backend Key: MESOS-2968 URL: https://issues.apache.org/jira/browse/MESOS-2968 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen Assignee: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2969) Support docker images discovery via Docker Registry v1 API
Timothy Chen created MESOS-2969: --- Summary: Support docker images discovery via Docker Registry v1 API Key: MESOS-2969 URL: https://issues.apache.org/jira/browse/MESOS-2969 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen Assignee: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2970) Support container image caching
Timothy Chen created MESOS-2970: --- Summary: Support container image caching Key: MESOS-2970 URL: https://issues.apache.org/jira/browse/MESOS-2970 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen Assignee: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2971) Add OverlayFS provisioner backend
Timothy Chen created MESOS-2971: --- Summary: Add OverlayFS provisioner backend Key: MESOS-2971 URL: https://issues.apache.org/jira/browse/MESOS-2971 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen Assignee: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2972) Serialize Docker image spec as protobuf
Timothy Chen created MESOS-2972: --- Summary: Serialize Docker image spec as protobuf Key: MESOS-2972 URL: https://issues.apache.org/jira/browse/MESOS-2972 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609368#comment-14609368 ] Jihun Kang commented on MESOS-2216: --- [~trex58], My patch made for Mesos 0.23.0, current development version, and this patch might not worked with older version of mesos. I also made a patch for 0.22.1, current maintenance version, and will attach to this jira issue. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2018) Dynamic Reservation
[
https://issues.apache.org/jira/browse/MESOS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609432#comment-14609432
]
Jay Taylor commented on MESOS-2018:
---
Dear [~adam-mesos],
Hey there, I've been keeping and eye on this story and am keenly looking
forward to the new capabilities which are made possible by this!
Will you please shed some light on why [MESOS-2018 _"Dynamic
Reservation"_|https://issues.apache.org/jira/browse/MESOS-2018] has been moved
to 0.24x (further into the future)?
Thank You!
Jay
> Dynamic Reservation
> ---
>
> Key: MESOS-2018
> URL: https://issues.apache.org/jira/browse/MESOS-2018
> Project: Mesos
> Issue Type: Epic
> Components: allocation, framework, master, slave
>Reporter: Adam B
>Assignee: Michael Park
>Priority: Critical
> Labels: mesosphere, offer, persistence, reservations, resource,
> stateful, storage
>
> h3. Overview
> This is a feature to provide better support for running stateful services on
> Mesos such as HDFS (Distributed Filesystem), Cassandra (Distributed
> Database), or MySQL (Local Database).
> Current resource reservations (henceforth called "static" reservations) are
> statically determined by the slave operator at slave start time, and
> individual frameworks have no authority to reserve resources themselves.
> Dynamic reservations allow a framework to dynamically reserve offered
> resources, such that those resources will only be re-offered to the same
> framework (or other frameworks with the same role).
> This is especially useful if the framework's task stored some state on the
> slave, and needs a guaranteed set of resources reserved so that it can
> re-launch a task on the same slave to recover that state.
> h3. Planned Stages
> 1. MESOS-2489: Enable a framework to perform reservation operations.
> The goal of this stage is to allow the framework to send back a
> Reserve/Unreserve operation which gets validated by the master and updates
> the allocator resources. The allocator's {{allocate}} logic is left unchanged
> and the resources get offered back to the framework's role as desired.
> 2. MESOS-2491: Persist the reservation state on the slave.
> The goal of this stage is to persist the reservation state on the slave.
> Currently the master knows to store the persistent volumes in the
> {{checkpointedResources}} data structure which gets sent to individual slaves
> to be checkpointed. We will update the master such that dynamically reserved
> resources are stored in the {{checkpointedResources}} as well. This stage
> also involves subtasks such as updating the slave re(register) logic to
> support slave re-starts.
> 3. MESOS-2600: Introduce reservation HTTP endpoints on the master.
> The goal of this stage is to enable operators to perform reservation
> operations via HTTP endpoints on the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2973) SSL tests don't work with --gtest_repeat
Joris Van Remoortere created MESOS-2973: --- Summary: SSL tests don't work with --gtest_repeat Key: MESOS-2973 URL: https://issues.apache.org/jira/browse/MESOS-2973 Project: Mesos Issue Type: Bug Components: libprocess Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2860) Create the basic infrastructure to handle /call endpoint
[
https://issues.apache.org/jira/browse/MESOS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607993#comment-14607993
]
Isabel Jimenez edited comment on MESOS-2860 at 7/1/15 1:59 AM:
---
https://reviews.apache.org/r/36037/
https://reviews.apache.org/r/36040/
https://reviews.apache.org/r/35934/
https://reviews.apache.org/r/35939/
https://reviews.apache.org/r/36073/
https://reviews.apache.org/r/36072/
was (Author: ijimenez):
https://reviews.apache.org/r/36037/
https://reviews.apache.org/r/36040/
https://reviews.apache.org/r/35934/
https://reviews.apache.org/r/35939/
> Create the basic infrastructure to handle /call endpoint
>
>
> Key: MESOS-2860
> URL: https://issues.apache.org/jira/browse/MESOS-2860
> Project: Mesos
> Issue Type: Story
> Components: master
>Reporter: Marco Massenzio
>Assignee: Isabel Jimenez
> Labels: mesosphere
>
> This is the first basic step in ensuring the basic {{/call}} functionality:
> processing a
> {noformat}
> POST /call
> {noformat}
> and returning:
> - {{202}} if all goes well;
> - {{401}} if not authorized; and
> - {{403}} if the request is malformed.
> We'll get more sophisticated as the work progressed (eg, supporting {{415}}
> if the content-type is not of the right kind).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2018) Dynamic Reservation
[
https://issues.apache.org/jira/browse/MESOS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609450#comment-14609450
]
Adam B commented on MESOS-2018:
---
I'll explain more in the 0.23 release blog post, but the short answer is that
SSL was the gating feature, and now that it's landed, we're ready to cut 0.23.
Persistent Volumes (MESOS-1554) and Dynamic Reservations are both mostly
complete, but there are a few unresolved issues left in those Epics. The
biggest remaining issue/feature is operator endpoints for /reserve, /unreserve,
and /destroy. Without these endpoints, a framework that does not shut down
cleanly may leave reservations/volumes lingering, without an easy way for the
operator to clean them up. (Workaround: create a cleanup framework that
registers as the same role and unreserves/destroys any reservations/volumes it
is offered.) As such, these features will be included in Mesos 0.23 in
alpha/experimental state, so you can start modifying your frameworks to use the
new APIs, but we would not recommend using them in a multi-framework production
environment. Mesos 0.24 is targeted for early August (before MesosCon), and I
am confident that those features will be production-ready by then.
> Dynamic Reservation
> ---
>
> Key: MESOS-2018
> URL: https://issues.apache.org/jira/browse/MESOS-2018
> Project: Mesos
> Issue Type: Epic
> Components: allocation, framework, master, slave
>Reporter: Adam B
>Assignee: Michael Park
>Priority: Critical
> Labels: mesosphere, offer, persistence, reservations, resource,
> stateful, storage
>
> h3. Overview
> This is a feature to provide better support for running stateful services on
> Mesos such as HDFS (Distributed Filesystem), Cassandra (Distributed
> Database), or MySQL (Local Database).
> Current resource reservations (henceforth called "static" reservations) are
> statically determined by the slave operator at slave start time, and
> individual frameworks have no authority to reserve resources themselves.
> Dynamic reservations allow a framework to dynamically reserve offered
> resources, such that those resources will only be re-offered to the same
> framework (or other frameworks with the same role).
> This is especially useful if the framework's task stored some state on the
> slave, and needs a guaranteed set of resources reserved so that it can
> re-launch a task on the same slave to recover that state.
> h3. Planned Stages
> 1. MESOS-2489: Enable a framework to perform reservation operations.
> The goal of this stage is to allow the framework to send back a
> Reserve/Unreserve operation which gets validated by the master and updates
> the allocator resources. The allocator's {{allocate}} logic is left unchanged
> and the resources get offered back to the framework's role as desired.
> 2. MESOS-2491: Persist the reservation state on the slave.
> The goal of this stage is to persist the reservation state on the slave.
> Currently the master knows to store the persistent volumes in the
> {{checkpointedResources}} data structure which gets sent to individual slaves
> to be checkpointed. We will update the master such that dynamically reserved
> resources are stored in the {{checkpointedResources}} as well. This stage
> also involves subtasks such as updating the slave re(register) logic to
> support slave re-starts.
> 3. MESOS-2600: Introduce reservation HTTP endpoints on the master.
> The goal of this stage is to enable operators to perform reservation
> operations via HTTP endpoints on the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2974) stout flags can't have their defaults reset
Joris Van Remoortere created MESOS-2974: --- Summary: stout flags can't have their defaults reset Key: MESOS-2974 URL: https://issues.apache.org/jira/browse/MESOS-2974 Project: Mesos Issue Type: Bug Components: stout Reporter: Joris Van Remoortere Stout flags don't remember their default values, and so can't have their defaults reset. This makes it hard to reset flags to their defaults between tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jihun Kang updated MESOS-2216: -- Attachment: MESOS-2216_1.patch This patch made for Mesos 0.22.1. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > Attachments: MESOS-2216_1.patch > > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2975) SSL tests don't work with --gtest-shuffle
Joris Van Remoortere created MESOS-2975: --- Summary: SSL tests don't work with --gtest-shuffle Key: MESOS-2975 URL: https://issues.apache.org/jira/browse/MESOS-2975 Project: Mesos Issue Type: Bug Components: libprocess Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609462#comment-14609462 ] Jihun Kang edited comment on MESOS-2216 at 7/1/15 2:21 AM: --- This patch made for Mesos 0.22.1. [~trex58], could you test it on your machines? was (Author: ykrips): This patch made for Mesos 0.22.1. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > Attachments: MESOS-2216_1.patch > > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2975) SSL tests don't work with --gtest_shuffle
[ https://issues.apache.org/jira/browse/MESOS-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Van Remoortere updated MESOS-2975: Summary: SSL tests don't work with --gtest_shuffle (was: SSL tests don't work with --gtest-shuffle) > SSL tests don't work with --gtest_shuffle > - > > Key: MESOS-2975 > URL: https://issues.apache.org/jira/browse/MESOS-2975 > Project: Mesos > Issue Type: Bug > Components: libprocess >Reporter: Joris Van Remoortere >Assignee: Joris Van Remoortere > Labels: ssl, testing > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The "configure" phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609523#comment-14609523 ] Jihun Kang commented on MESOS-2216: --- I ran several test cases with OpenJDK 7, and I also got an segmentation fault error when I running a reservation test. This might be come with my misconfiguration on my laptop. > The "configure" phase breaks with the IBM JVM. > -- > > Key: MESOS-2216 > URL: https://issues.apache.org/jira/browse/MESOS-2216 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.1, 1.0.0 > Environment: Ubuntu / x86_64 >Reporter: Tony Reix > Attachments: MESOS-2216_1.patch > > > ./configure does not work with IBM JVM, since it looks for a directory: >/usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 >/usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE > that does not exist for the IBM JVM. > Though this directory does exist for Oracle JVM and Open JDK: >/usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM >/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK > However, the files: > libjsig.so > libjvm.so (3 versions) > do exist for IBM JVM. > Anyway, creating the server directory and copying the files (tried with the 3 > versions of libjvm.so) does not fix the issue: > checking whether or not we can build with JNI... > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlopen' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlclose' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlerror' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dlsym' > /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined > reference to `dladdr' > Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. > So, either the configure step relies on a feature that is not in the Java > standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of > the Java standard. > I'm not an expert about this. So, I'd like Mesos people to experiment with > IBM JVM. Maybe there is another solution for this step of the Mesos configure > that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2551) C++ Scheduler library should send Call messages to Master
[ https://issues.apache.org/jira/browse/MESOS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600433#comment-14600433 ] Vinod Kone edited comment on MESOS-2551 at 7/1/15 5:29 AM: --- https://reviews.apache.org/r/36077/ https://reviews.apache.org/r/36078/ https://reviews.apache.org/r/35855/ https://reviews.apache.org/r/35856/ https://reviews.apache.org/r/35857/ https://reviews.apache.org/r/35858/ https://reviews.apache.org/r/36079/ was (Author: vinodkone): https://reviews.apache.org/r/35855/ https://reviews.apache.org/r/35856/ https://reviews.apache.org/r/35857/ https://reviews.apache.org/r/35858/ TODO: SUBSCRIBE call. > C++ Scheduler library should send Call messages to Master > - > > Key: MESOS-2551 > URL: https://issues.apache.org/jira/browse/MESOS-2551 > Project: Mesos > Issue Type: Story >Reporter: Vinod Kone >Assignee: Vinod Kone > Labels: tech-debt, twitter > > Currently, the C++ library sends different messages to Master instead of a > single Call message. To vet the new Call API it should send Call messages. > Master should be updated to handle all types of Calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
