Re: Review Request 19901: Added Termination protobuf message.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19901/#review39237 --- Patch looks great! Reviews applied: [19901] All tests passed. - Mesos ReviewBot On April 2, 2014, 5:20 a.m., Till Toenshoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19901/ --- (Updated April 2, 2014, 5:20 a.m.) Review request for mesos, Ian Downes, Niklas Nielsen, and Vinod Kone. Repository: mesos-git Description --- Replaced slave::Containerizer::Termination with a protobuf message called Termination for allowing it to be reused in ExternalContainerizer, gaining a serializable Termination message. Diffs - include/mesos/mesos.proto 37f8a7f src/slave/containerizer/containerizer.hpp d9ae326 src/slave/containerizer/mesos_containerizer.hpp ee1fd30 src/slave/containerizer/mesos_containerizer.cpp c819c97 src/slave/slave.hpp 15e23ce src/slave/slave.cpp a356f5f src/tests/containerizer.hpp a9f1531 src/tests/containerizer.cpp bfb9341 Diff: https://reviews.apache.org/r/19901/diff/ Testing --- make check Thanks, Till Toenshoff
Re: Review Request 17567: Added External Containerizer.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/#review39245 --- Bad patch! Reviews applied: [19795, 18403, 17567] Failed command: git apply --index 17567.patch Error: error: patch failed: src/slave/flags.hpp:196 error: src/slave/flags.hpp: patch does not apply - Mesos ReviewBot On April 2, 2014, 2:02 a.m., Till Toenshoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/ --- (Updated April 2, 2014, 2:02 a.m.) Review request for mesos, Ian Downes, Niklas Nielsen, and Vinod Kone. Bugs: MESOS-816 https://issues.apache.org/jira/browse/MESOS-816 Repository: mesos-git Description --- This patch adds the so-called external containerizer. This containerizer delegates all containerizer calls directly to an external containerizer program (which can be specified on start-up). Few calls have internal fall-back implementations such as wait(), destroy() and usage(). The protocol for the interactions with the external program is as follows: COMMAND (ADDITIONAL-PARAMETERS) INPUT-PROTO RESULT-PROTO launch (ContainerID, --mesos-executor, path) TaskInfo ExternalStatus update (ContainerID) ResourceArray ExternalStatus usage (ContainerID) ResourceStatistics wait (ContainerID) ExternalTermination destroy (ContainerID) ExternalStatus When protocol buffers need to be provided, the Mesos side of the external containerizer implementation will serialize the protos on stdin and vice-versa for reading protos on stdout as drafted in the above scheme. NOTE: This is currently work in progress to cover all comments. Diffs - configure.ac 5404dc2 include/mesos/mesos.proto 37f8a7f src/Makefile.am 0775a0d src/examples/python/test-containerizer.in PRE-CREATION src/examples/python/test_containerizer.py PRE-CREATION src/slave/containerizer/containerizer.cpp 6de091e src/slave/containerizer/external_containerizer.hpp PRE-CREATION src/slave/containerizer/external_containerizer.cpp PRE-CREATION src/slave/flags.hpp c9a627b src/tests/external_containerizer_test.cpp PRE-CREATION Diff: https://reviews.apache.org/r/17567/diff/ Testing --- make check and functional testing. Thanks, Till Toenshoff
Re: Fair sharing question: Should it be among frameworks or among users?
Hi Li, I recently got a chance to dig deeper into the resource allocator code and want to share what I learned. Mesos already distributes its resource offers primarily by 'user' and secondarily by framework. However, the 'user' referred to is the user running/registering the framework, which isn't really what you're looking for. But I do think Mesos could be adapted to solve your use case. Here's how it works now: 1. When a framework registers, it species a user in its FrameworkInfo (framework-user). If set to empty string, Mesos will set it to current user running the framework scheduler. 2. When the master decides which framework to offer its resources to next, it first looks at which framework-user has the lowest share, then which framework belonging to that user has the lowest share. 3. When a framework receives an offer, it decides whether to accept or decline the offer, and what task(s) to run with that offer. 4. When a task runs, it runs as the user specified in the FrameworkInfo. MESOS-1161 will allow the framework to set a different user per task (task-user) in the CommandInfo when launching each task, getting us one step closer to what you want. But even once frameworks can run tasks as different users, the master allocator still won't know which users want to launch tasks before it allocates a resource offer to a framework. This is why Mesos is known as a two level scheduler: first the master allocator makes a global decision, then framework scheduler decides within its own realm. Relying on the master allocator alone could work fine for you if each user launches a new framework instance for each job they want to run, but does not work for long-running services that take task requests from multiple users. Relying on the framework scheduler could work for you if you only care about a single framework on the cluster, but won't help you balance users between multiple frameworks. If I understand correctly, you want to schedule primarily based on the resource shares currently allocated to the various users running the tasks, regardless of how many different frameworks there are, or what users are running the frameworks themselves. Mesos' DRF sorter/allocator approach could still be used to provide dominant resource fairness among task-users, but it would need a few additional pieces of information. First, frameworks would have to update the master allocator with a list of users wanting to launch tasks; this could be added to the existing resource request message. Secondly, the master would need to track the resources allocated to each user's tasks. Then the master could use the existing DRF algorithm to select the task-user furthest below his/her fair share, then select which of that user's frameworks to give the offer to, and pass the user selection to the selected framework along with the resource offer. In summary, I do believe that Mesos can be adapted to allocate resource shares among task-users, but we will need to flesh out the design and implement it. Personally, I find the idea fascinating. Please share more information about your use case and requirements, and even file a new JIRA for this feature if you like. Thank you, -Adam- mesosphere.io On Tue, Mar 25, 2014 at 9:40 PM, Li Jin ice.xell...@gmail.com wrote: Thanks again for the reply. I should clarify I am considering the case where U1-U10 having unlimited requests. And I would like to give freed-up resource to the users (U1-U10) with the minimum drs instead of the framework (A,B,C) with mininum drs. I am curious in how other people think and open to discussion. On Wed, Mar 26, 2014 at 12:12 AM, Chengwei Yang chengwei.yang...@gmail.comwrote: On Tue, Mar 25, 2014 at 11:45:18PM -0400, Li Jin wrote: Thanks for the reply. Still, it's not clear to me how DRF would help in this case, let me elaborate: Let's say there are 3 frameworks A,B,C, running by user F1, F2, F3 and there are 10 users, U1-U10, running tasks through A,B,C. Now use DRF between framework with equal weight, I believe the resource will be equally distributed among the 3 frameworks. Is it possible for Mesos to equally distribute the resource among the 10 users? The simple answer is *NO*, DRF isn't a equal partition of resource, no one need equal partition in fact, it always depends on the resource request. The resource allocation is a dynamic progress, not a static partition for all available sources, thinking that there may be only a few users run tasks at the same time slot. For example, if there are more than one user and more than one tasks ready to run. Then, the DRF for user first selects user who has the minimum dominant resource share, if there are more than one tasks (say framework A task, framework B task, ...), then it selects the framework task which has the minimum dominant resource share. BTW, just my understanding from the paper, any mistake please correct me. -- Thanks,
Re: Fair sharing question: Should it be among frameworks or among users?
Hey all, This is a very interesting discussion, and i’m keen to see where it goes. I’m particularly interested in the point you made Adam about each user launching their own framework… To me this seems like a very decent approach, take for example multiple users all executing different pipelines of jobs (a mix between Hadoop and Spark) – the running time of a single task is quite short, so the opportunities to re-distribute the resource share among each user are frequent. Imagine if each user, before invoking their pipelines launched a Hadoop JobTracker and Spark Master *locally* which registered itself as a framework with the Mesos cluster under their own user. They would then launch their tasks through those local frameworks and Mesos would take care of scheduling users, and then frameworks. It seems that this would work quite well with what you’re describing? I’m curious if anyone else has investigated taking the above approach, and if they found any issues with the increased network traffic between the client and the cluster. If the network prohibits this, you could even launch the per-user Hadoop JobTracker and Spark Master instances on the Mesos cluster itself with a fairly simple framework (Marathon could probably do that quite well). Thanks, Tom. -- Tom Arnfeld Developer // DueDil t...@duedil.com (+44) 7525940046 8 Warner Yard, Second Floor, London. EC1R 5EY Company Number: 06999618 What is DueDil? | Product features | Try it for free On 2 Apr 2014, at 09:06, Adam Bordelon a...@mesosphere.io wrote: Hi Li, I recently got a chance to dig deeper into the resource allocator code and want to share what I learned. Mesos already distributes its resource offers primarily by 'user' and secondarily by framework. However, the 'user' referred to is the user running/registering the framework, which isn't really what you're looking for. But I do think Mesos could be adapted to solve your use case. Here's how it works now: 1. When a framework registers, it species a user in its FrameworkInfo (framework-user). If set to empty string, Mesos will set it to current user running the framework scheduler. 2. When the master decides which framework to offer its resources to next, it first looks at which framework-user has the lowest share, then which framework belonging to that user has the lowest share. 3. When a framework receives an offer, it decides whether to accept or decline the offer, and what task(s) to run with that offer. 4. When a task runs, it runs as the user specified in the FrameworkInfo. MESOS-1161 will allow the framework to set a different user per task (task-user) in the CommandInfo when launching each task, getting us one step closer to what you want. But even once frameworks can run tasks as different users, the master allocator still won't know which users want to launch tasks before it allocates a resource offer to a framework. This is why Mesos is known as a two level scheduler: first the master allocator makes a global decision, then framework scheduler decides within its own realm. Relying on the master allocator alone could work fine for you if each user launches a new framework instance for each job they want to run, but does not work for long-running services that take task requests from multiple users. Relying on the framework scheduler could work for you if you only care about a single framework on the cluster, but won't help you balance users between multiple frameworks. If I understand correctly, you want to schedule primarily based on the resource shares currently allocated to the various users running the tasks, regardless of how many different frameworks there are, or what users are running the frameworks themselves. Mesos' DRF sorter/allocator approach could still be used to provide dominant resource fairness among task-users, but it would need a few additional pieces of information. First, frameworks would have to update the master allocator with a list of users wanting to launch tasks; this could be added to the existing resource request message. Secondly, the master would need to track the resources allocated to each user's tasks. Then the master could use the existing DRF algorithm to select the task-user furthest below his/her fair share, then select which of that user's frameworks to give the offer to, and pass the user selection to the selected framework along with the resource offer. In summary, I do believe that Mesos can be adapted to allocate resource shares among task-users, but we will need to flesh out the design and implement it. Personally, I find the idea fascinating. Please share more information about your use case and requirements, and even file a new JIRA for this feature if you like. Thank you, -Adam- mesosphere.io On Tue, Mar 25, 2014 at 9:40 PM, Li Jin ice.xell...@gmail.com wrote: Thanks again for the reply. I should clarify I am considering the case
Re: Review Request 19901: Added Termination protobuf message.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19901/#review39266 --- Ship it! include/mesos/mesos.proto https://reviews.apache.org/r/19901/#comment71628 I think we can simplify this sentence; the container can be killed for various reasons - register timeout, in error states and so on. I don't think we need to capture this here :) - Niklas Nielsen On April 1, 2014, 10:20 p.m., Till Toenshoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19901/ --- (Updated April 1, 2014, 10:20 p.m.) Review request for mesos, Ian Downes, Niklas Nielsen, and Vinod Kone. Repository: mesos-git Description --- Replaced slave::Containerizer::Termination with a protobuf message called Termination for allowing it to be reused in ExternalContainerizer, gaining a serializable Termination message. Diffs - include/mesos/mesos.proto 37f8a7f src/slave/containerizer/containerizer.hpp d9ae326 src/slave/containerizer/mesos_containerizer.hpp ee1fd30 src/slave/containerizer/mesos_containerizer.cpp c819c97 src/slave/slave.hpp 15e23ce src/slave/slave.cpp a356f5f src/tests/containerizer.hpp a9f1531 src/tests/containerizer.cpp bfb9341 Diff: https://reviews.apache.org/r/19901/diff/ Testing --- make check Thanks, Till Toenshoff
Re: Review Request 19795: Changed Executor::info to executor info future.
On April 1, 2014, 11:51 a.m., Niklas Nielsen wrote: src/slave/slave.cpp, lines 3502-3514 https://reviews.apache.org/r/19795/diff/2/?file=543982#file543982line3502 I chatted with BenH about this and I think we have an approach to do proper clean-up of orphan containers. Updated RR will follow. I took a stab at it in the latest patch. If the executor info is not present in the directory (which will be the case if the slave fails over during launch), the executor state will still be available (as we create the directory up front, just without the info saved). The new patch destroys the container if this happens. I am still thinking about a good test for this and am open to suggestions. - Niklas --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19795/#review39190 --- On April 1, 2014, 6:45 p.m., Niklas Nielsen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19795/ --- (Updated April 1, 2014, 6:45 p.m.) Review request for mesos, Ian Downes and Vinod Kone. Bugs: MESOS-922 https://issues.apache.org/jira/browse/MESOS-922 Repository: mesos-git Description --- This is the 2nd part of the task-info patch split (https://reviews.apache.org/r/18403/) and changes Executor::info to an executor info future. This is motivated by delegating executor info creation/choice to the containerizer to address new container/executor scenarios (https://issues.apache.org/jira/browse/MESOS-922). This patch use the new Executor::info and introduces new continuations to deal with launching containers i.e. executor infos are to be determined. Diffs - src/slave/http.cpp 594032d src/slave/slave.hpp 15e23ce src/slave/slave.cpp a356f5f Diff: https://reviews.apache.org/r/19795/diff/ Testing --- make check Thanks, Niklas Nielsen
Re: [VOTE] Release Apache Mesos 0.18.0 (rc6)
+1, built and checked on OS X 10.9.2, clang-503.0.38 Ubuntu 13.10, gcc 4.8.1 Niklas On Tue, Apr 1, 2014 at 10:46 PM, Till Toenshoff toensh...@me.com wrote: +1 Builds and checks fine on OSX 10.9.2, clang 3.4 (Xcode5.1). On Apr 2, 2014, at 5:35 AM, Vinod Kone vinodk...@gmail.com wrote: Hi all, Please vote on releasing the following candidate as Apache Mesos 0.18.0. 0.18.0 includes the following: * The primary feature of this release is a refactor of the isolation abstraction to make it easy to add pluggable isolators/containerizers. The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.18.0-rc6 The candidate for Mesos 0.18.0 release is available at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz The tag to be voted on is 0.18.0-rc6: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.0-rc6 The MD5 checksum of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.md5 The signature of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.asc The PGP key used to sign the release is here: https://dist.apache.org/repos/dist/release/mesos/KEYS The JAR is up in Maven in a staging repository here: https://repository.apache.org/content/repositories/orgapachemesos-1013 Please vote on releasing this package as Apache Mesos 0.18.0! The vote is open until Fri Apr 4 20:29:44 PDT 2014 and passes if a majority of at least 3 +1 PMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.18.0 [ ] -1 Do not release this package because ... Thanks,
Re: Review Request 19162: Added optional envvar map to subprocess.
On March 31, 2014, 6:23 p.m., Adam B wrote: 3rdparty/libprocess/src/subprocess.cpp, lines 102-104 https://reviews.apache.org/r/19162/diff/9/?file=530839#file530839line102 This only deletes the strings for the child environment and leaves the parent env strings alone, right? Is this intentional? Please fix or comment. This is intentional - The parent env strings are pointers to the global environment so not owned by this code. - Dominic --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/#review39120 --- On March 26, 2014, 11:54 a.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated March 26, 2014, 11:54 a.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
[jira] [Updated] (MESOS-1178) Only enable the oom killer if it's not enabled
[ https://issues.apache.org/jira/browse/MESOS-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Downes updated MESOS-1178: -- Fix Version/s: 0.19.0 Only enable the oom killer if it's not enabled -- Key: MESOS-1178 URL: https://issues.apache.org/jira/browse/MESOS-1178 Project: Mesos Issue Type: Bug Components: isolation Affects Versions: 0.17.0, 0.18.0 Reporter: Ian Downes Assignee: Ian Downes Priority: Minor Fix For: 0.19.0 When the cgroups memory isolator is used Mesos will always try to enable the kernel oom killer by writing 0 to the memory.oom_control file. This will fail if memory.use_hierarchy is enabled on a parent cgroup, *even* if the oom killer is already enabled. We should attempt to enable the oom killer only if it is not enabled. This was observed on a Fedora 20 box which had memory.use_hierarchy enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1178) Only enable the oom killer if it's not enabled
Ian Downes created MESOS-1178: - Summary: Only enable the oom killer if it's not enabled Key: MESOS-1178 URL: https://issues.apache.org/jira/browse/MESOS-1178 Project: Mesos Issue Type: Bug Components: isolation Affects Versions: 0.17.0, 0.18.0 Reporter: Ian Downes Assignee: Ian Downes Priority: Minor When the cgroups memory isolator is used Mesos will always try to enable the kernel oom killer by writing 0 to the memory.oom_control file. This will fail if memory.use_hierarchy is enabled on a parent cgroup, *even* if the oom killer is already enabled. We should attempt to enable the oom killer only if it is not enabled. This was observed on a Fedora 20 box which had memory.use_hierarchy enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39301 --- 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp https://reviews.apache.org/r/19948/#comment71646 this isn't necessarily malformed: MY_FILTER='--gtest_filter=Metric*' 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp https://reviews.apache.org/r/19948/#comment71647 const mapstring, string ? 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp https://reviews.apache.org/r/19948/#comment71648 needed for this review? - Dominic Hamon On April 2, 2014, 10:32 a.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 10:32 a.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19948: Added os::environment.
On April 2, 2014, 5:35 p.m., Dominic Hamon wrote: 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp, line 123 https://reviews.apache.org/r/19948/diff/1/?file=545964#file545964line123 this isn't necessarily malformed: MY_FILTER='--gtest_filter=Metric*' Of course, thanks! I'll update the code and add a test. On April 2, 2014, 5:35 p.m., Dominic Hamon wrote: 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp, line 297 https://reviews.apache.org/r/19948/diff/1/?file=545965#file545965line297 needed for this review? I added 'using std::vector' so it's just housekeeping. - Benjamin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39301 --- On April 2, 2014, 5:32 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:32 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19162: Added optional envvar map to subprocess.
On March 24, 2014, 8:51 p.m., Ben Mahler wrote: 3rdparty/libprocess/src/subprocess.cpp, lines 63-64 https://reviews.apache.org/r/19162/diff/9/?file=530839#file530839line63 What's not clear from reading this code is that our technique here is to reserve the first [0,size) envp entries for our allocated additional environment data, and the (size, ...] entries for the parent 'environ' data. This seems a bit confusing since I would normally expect 'size' to refer to the size of the array. Would it be simpler to just have envp contain our own allocated data (some copied from 'environ' rather than borrowed, some copied from 'environment'). This would more closely model what things will look like when we implement the TODO for os::environment. Also, you're currently placing the parent environment *after* the child environment, can you add a test that the child environment overrides what's contained in the parent environment? I'm wondering how execle deals with duplicate keys. Let's clean all this up with https://reviews.apache.org/r/19948. - Benjamin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/#review38361 --- On March 26, 2014, 6:54 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated March 26, 2014, 6:54 p.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:50 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Changes --- Updates from review comments. Repository: mesos-git Description --- See summary. Diffs (updated) - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:51 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Changes --- Updates from review comments. Repository: mesos-git Description --- See summary. Diffs (updated) - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:52 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Changes --- Updates from review comments. Repository: mesos-git Description --- See summary. Diffs (updated) - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 18155: High Availability doc update
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18155/ --- (Updated April 2, 2014, 5:52 p.m.) Review request for mesos and Jiang Yan Xu. Changes --- Assigning Yan as shepherd -- Vinod. Tom, can you address the comments to get this committed? Repository: mesos-git Description --- Updated version of high availability doc. Diffs (updated) - docs/high-availability.md 77af5d5 Diff: https://reviews.apache.org/r/18155/diff/ Testing --- Thanks, Tom Galloway
Re: Review Request 19948: Added os::environment.
On April 2, 2014, 5:35 p.m., Dominic Hamon wrote: 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp, line 76 https://reviews.apache.org/r/19948/diff/1/?file=545965#file545965line76 const mapstring, string ? I use the '[]' operator which requires non-const. - Benjamin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39301 --- On April 2, 2014, 5:52 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:52 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 16625: Created cgroups::detached() to wait for all attached subsystems to be detached.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16625/ --- (Updated April 2, 2014, 5:53 p.m.) Review request for mesos and Ian Downes. Changes --- Assigning to Ian to shepherd -- Vinod. Bugs: MESOS-891 https://issues.apache.org/jira/browse/MESOS-891 Repository: mesos-git Description --- - Not all subsystems are immediately detached after cgroups::cleanup() exits. - Cgroups-related test cases now wait for detached() after calling cgroups::cleanup() in *TearDown(). - cgroups::detached() is a separate function instead of being embedded in cgroups::cleanup() because cgroups::cleanup() does not always detach all subsystems. - a single subsystem can be attached to two hierarchies if both of those hierarchies have only that subsystem attached.: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Relationships_Between_Subsystems_Hierarchies_Control_Groups_and_Tasks.html Diffs - src/linux/cgroups.hpp cefa476cffb7de50925387a83526ef2f84d7d69c src/linux/cgroups.cpp 19ab1f348191ab0315271477b206aa8c6456fd5a src/tests/cgroups_tests.cpp 0e9316d6561a1339bd2a3fb3482277658beba12b src/tests/mesos.cpp 5359394f45475803e05d281710139e8cbe7c7364 Diff: https://reviews.apache.org/r/16625/diff/ Testing --- make check ./bin/mesos-tests.sh -j --gtest_filter=SlaveRecoveryTest/1.SchedulerFailover --gtest_repeat=1000 Thanks, Jiang Yan Xu
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39313 --- Ship it! Ship It! 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp https://reviews.apache.org/r/19948/#comment71658 an alternative test to this would be to setenv whatever test cases you are interested in and check specifically for those. - Dominic Hamon On April 2, 2014, 10:52 a.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 10:52 a.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 18288: Hided the log storage implementation from replica.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18288/ --- (Updated April 2, 2014, 5:55 p.m.) Review request for mesos and Benjamin Hindman. Changes --- Assigning to BenH to shepherd -- Vinod. Repository: mesos-git Description --- See summary. Needed by a followup review on log recover test. Diffs - src/Makefile.am e02d416e5cb8edf6c44ed05c5785a5084bf02abb src/log/replica.cpp 746d6c35c9255775ab6e70b0daf1dcecf63c16a0 src/log/storage.hpp c0eba1b34835a89698e84c75a4c301ed7370ea1c src/log/storage.cpp PRE-CREATION Diff: https://reviews.apache.org/r/18288/diff/ Testing --- make check Thanks, Jie Yu
Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- Review request for mesos, Jie Yu and Vinod Kone. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
Re: Review Request 18289: Added a log recover test for testing catch-up when positions are large.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18289/#review39314 --- Jie. Can you commit this? - Vinod Kone On March 5, 2014, 6:17 p.m., Jie Yu wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18289/ --- (Updated March 5, 2014, 6:17 p.m.) Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - src/tests/log_tests.cpp 2613e414942fc6ff6e312fd8145567679e2545fb Diff: https://reviews.apache.org/r/18289/diff/ Testing --- make check bin/mesos-tests.sh --gtest_filter=*LargePositions* --gtest_repeat=100 Thanks, Jie Yu
Re: Review Request 19162: Added optional envvar map to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated April 2, 2014, 10:59 a.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Changes --- added dependency Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
Re: [VOTE] Release Apache Mesos 0.18.0 (rc6)
+1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2 On Wed, Apr 2, 2014 at 10:02 AM, Niklas Nielsen n...@qni.dk wrote: +1, built and checked on OS X 10.9.2, clang-503.0.38 Ubuntu 13.10, gcc 4.8.1 Niklas On Tue, Apr 1, 2014 at 10:46 PM, Till Toenshoff toensh...@me.com wrote: +1 Builds and checks fine on OSX 10.9.2, clang 3.4 (Xcode5.1). On Apr 2, 2014, at 5:35 AM, Vinod Kone vinodk...@gmail.com wrote: Hi all, Please vote on releasing the following candidate as Apache Mesos 0.18.0. 0.18.0 includes the following: * The primary feature of this release is a refactor of the isolation abstraction to make it easy to add pluggable isolators/containerizers. The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.18.0-rc6 The candidate for Mesos 0.18.0 release is available at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz The tag to be voted on is 0.18.0-rc6: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.0-rc6 The MD5 checksum of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.md5 The signature of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.asc The PGP key used to sign the release is here: https://dist.apache.org/repos/dist/release/mesos/KEYS The JAR is up in Maven in a staging repository here: https://repository.apache.org/content/repositories/orgapachemesos-1013 Please vote on releasing this package as Apache Mesos 0.18.0! The vote is open until Fri Apr 4 20:29:44 PDT 2014 and passes if a majority of at least 3 +1 PMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.18.0 [ ] -1 Do not release this package because ... Thanks,
Re: [VOTE] Release Apache Mesos 0.18.0 (rc6)
(Sending again, including user@ as well) +1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2 On Wed, Apr 2, 2014 at 11:06 AM, Adam Bordelon a...@mesosphere.io wrote: +1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2 On Wed, Apr 2, 2014 at 10:02 AM, Niklas Nielsen n...@qni.dk wrote: +1, built and checked on OS X 10.9.2, clang-503.0.38 Ubuntu 13.10, gcc 4.8.1 Niklas On Tue, Apr 1, 2014 at 10:46 PM, Till Toenshoff toensh...@me.com wrote: +1 Builds and checks fine on OSX 10.9.2, clang 3.4 (Xcode5.1). On Apr 2, 2014, at 5:35 AM, Vinod Kone vinodk...@gmail.com wrote: Hi all, Please vote on releasing the following candidate as Apache Mesos 0.18.0. 0.18.0 includes the following: * The primary feature of this release is a refactor of the isolation abstraction to make it easy to add pluggable isolators/containerizers. The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.18.0-rc6 The candidate for Mesos 0.18.0 release is available at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz The tag to be voted on is 0.18.0-rc6: https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.0-rc6 The MD5 checksum of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.md5 The signature of the tarball can be found at: https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.asc The PGP key used to sign the release is here: https://dist.apache.org/repos/dist/release/mesos/KEYS The JAR is up in Maven in a staging repository here: https://repository.apache.org/content/repositories/orgapachemesos-1013 Please vote on releasing this package as Apache Mesos 0.18.0! The vote is open until Fri Apr 4 20:29:44 PDT 2014 and passes if a majority of at least 3 +1 PMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.18.0 [ ] -1 Do not release this package because ... Thanks,
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39319 --- Patch looks great! Reviews applied: [19948] All tests passed. - Mesos ReviewBot On April 2, 2014, 5:52 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:52 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: [VOTE] Release Apache Mesos 0.18.0 (rc6)
I haven't tried building one of these packages before, and I ran into an
issue with Python when configuring the build directory. Has anybody else
seen this?
This is on Mac OS X v10.9.2
1. Downloaded mesos-0.18.0.tar.gz
2. Expanded tar.gz
3. Created subdirectory build
4. cd'd to build
5. Ran `../configure`
checking for a Python interpreter with version = 2.6... python
checking for python... /usr/local/bin/python
checking for python version... 2.7
checking for python platform... darwin
checking for python script directory...
${prefix}/lib/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.7/site-packages
checking for python2.7... (cached) /usr/local/bin/python
checking for a version of Python = '2.1.0'... yes
checking for a version of Python = '2.6'... yes
checking for the distutils Python package... yes
checking for Python include path...
-I/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/include/python2.7
checking for Python library path...
-L/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib
-lpython2.7
checking for Python site-packages path...
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
checking python extra libraries... -ldl -framework CoreFoundation
checking python extra linking flags... -u _PyMac_Error
Python.framework/Versions/2.7/Python
checking consistency of all components of python development environment...
no
configure: error: in `/Users/rossallen/Pops/mesos-0.18.0/build':
configure: error:
Could not link test program to Python. Maybe the main Python library has
been
installed in some non-standard library path. If so, pass it to configure,
via the LDFLAGS environment variable.
Example: ./configure LDFLAGS=-L/usr/non-standard-path/python/lib
ERROR!
You probably have to install the development version of the Python
package
for your distribution. The exact name of this package varies among them.
Ross Allen
r...@mesosphere.io
On 2 April 2014 11:06, Adam Bordelon a...@mesosphere.io wrote:
+1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2
On Wed, Apr 2, 2014 at 10:02 AM, Niklas Nielsen n...@qni.dk wrote:
+1, built and checked on OS X 10.9.2, clang-503.0.38 Ubuntu 13.10, gcc
4.8.1
Niklas
On Tue, Apr 1, 2014 at 10:46 PM, Till Toenshoff toensh...@me.com
wrote:
+1 Builds and checks fine on OSX 10.9.2, clang 3.4 (Xcode5.1).
On Apr 2, 2014, at 5:35 AM, Vinod Kone vinodk...@gmail.com wrote:
Hi all,
Please vote on releasing the following candidate as Apache Mesos
0.18.0.
0.18.0 includes the following:
* The primary feature of this release is a refactor of the isolation
abstraction to make it easy to add pluggable
isolators/containerizers.
The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.18.0-rc6
The candidate for Mesos 0.18.0 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz
The tag to be voted on is 0.18.0-rc6:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.0-rc6
The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.md5
The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.asc
The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS
The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1013
Please vote on releasing this package as Apache Mesos 0.18.0!
The vote is open until Fri Apr 4 20:29:44 PDT 2014 and passes if a
majority of at least 3 +1 PMC votes are cast.
[ ] +1 Release this package as Apache Mesos 0.18.0
[ ] -1 Do not release this package because ...
Thanks,
[jira] [Created] (MESOS-1179) Get ZooKeeper timeout from configuration
Daniel Fry created MESOS-1179: - Summary: Get ZooKeeper timeout from configuration Key: MESOS-1179 URL: https://issues.apache.org/jira/browse/MESOS-1179 Project: Mesos Issue Type: Improvement Reporter: Daniel Fry The documentation makes reference to a ZOOKEEPER_SESSION_TIMEOUT that doesnt actually exist. It has since been split into separate constants for detector contender, with the following doc: //TODO(benh): Get ZooKeeper timeout from configuration. https://github.com/apache/mesos/blob/bcd1dc4e10a1cff4fdc4e92daff108b6fa0475d3/src/master/detector.cpp#L222 I spent some time searching for this config attribute, and figured i'd add a Jira, thanks! -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/#review39331 --- Patch looks great! Reviews applied: [19952] All tests passed. - Mesos ReviewBot On April 2, 2014, 5:55 p.m., Ian Downes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- (Updated April 2, 2014, 5:55 p.m.) Review request for mesos, Jie Yu and Vinod Kone. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39330 --- 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp https://reviews.apache.org/r/19948/#comment71677 why not hashmap? 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp https://reviews.apache.org/r/19948/#comment71680 Can you also take this opportunity to cleanup FlagsBase::extract() to use os::environment() instead of os::environ()? That's the only place where it is used afaict. 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp https://reviews.apache.org/r/19948/#comment71679 this could be EXPECT_TRUE(environment.contains(key)) if os::environment returns a hashmap. - Vinod Kone On April 2, 2014, 5:52 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 5:52 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/#review39334 --- 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp https://reviews.apache.org/r/19952/#comment71685 Also, you can kill this :) - Vinod Kone On April 2, 2014, 5:55 p.m., Ian Downes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- (Updated April 2, 2014, 5:55 p.m.) Review request for mesos, Jie Yu and Vinod Kone. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 7:38 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Changes --- Updates based on review comments. Repository: mesos-git Description --- See summary. Diffs (updated) - 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 883926be92cada1ab93441fcbe9c4d93fe7b39ff 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39337 --- 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp https://reviews.apache.org/r/19948/#comment71688 this isn't necessary any more - Dominic Hamon On April 2, 2014, 12:38 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 12:38 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 883926be92cada1ab93441fcbe9c4d93fe7b39ff 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 19948: Added os::environment.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/#review39338 --- Ship it! Ship It! - Vinod Kone On April 2, 2014, 7:38 p.m., Benjamin Hindman wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19948/ --- (Updated April 2, 2014, 7:38 p.m.) Review request for mesos, Dominic Hamon and Vinod Kone. Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 883926be92cada1ab93441fcbe9c4d93fe7b39ff 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 901e5550c82c12934a6b9c3154f030c677e41a38 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 1babc1892dff0026c5d12178616a7a8457858eaa Diff: https://reviews.apache.org/r/19948/diff/ Testing --- make check Thanks, Benjamin Hindman
Re: Review Request 16625: Created cgroups::detached() to wait for all attached subsystems to be detached.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16625/#review39345 --- Bad patch! Reviews applied: [16625] Failed command: git apply --index 16625.patch Error: error: patch failed: src/linux/cgroups.cpp:1815 error: src/linux/cgroups.cpp: patch does not apply error: patch failed: src/tests/cgroups_tests.cpp:154 error: src/tests/cgroups_tests.cpp: patch does not apply error: patch failed: src/tests/mesos.cpp:249 error: src/tests/mesos.cpp: patch does not apply - Mesos ReviewBot On April 2, 2014, 5:53 p.m., Jiang Yan Xu wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16625/ --- (Updated April 2, 2014, 5:53 p.m.) Review request for mesos and Ian Downes. Bugs: MESOS-891 https://issues.apache.org/jira/browse/MESOS-891 Repository: mesos-git Description --- - Not all subsystems are immediately detached after cgroups::cleanup() exits. - Cgroups-related test cases now wait for detached() after calling cgroups::cleanup() in *TearDown(). - cgroups::detached() is a separate function instead of being embedded in cgroups::cleanup() because cgroups::cleanup() does not always detach all subsystems. - a single subsystem can be attached to two hierarchies if both of those hierarchies have only that subsystem attached.: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Relationships_Between_Subsystems_Hierarchies_Control_Groups_and_Tasks.html Diffs - src/linux/cgroups.hpp cefa476cffb7de50925387a83526ef2f84d7d69c src/linux/cgroups.cpp 19ab1f348191ab0315271477b206aa8c6456fd5a src/tests/cgroups_tests.cpp 0e9316d6561a1339bd2a3fb3482277658beba12b src/tests/mesos.cpp 5359394f45475803e05d281710139e8cbe7c7364 Diff: https://reviews.apache.org/r/16625/diff/ Testing --- make check ./bin/mesos-tests.sh -j --gtest_filter=SlaveRecoveryTest/1.SchedulerFailover --gtest_repeat=1000 Thanks, Jiang Yan Xu
Re: Review Request 19162: Added optional envvar map to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated April 2, 2014, 1:44 p.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Changes --- use os::environment Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs (updated) - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui #2033
See
https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2033/changes
Changes:
[benjamin.hindman] Added os::environment.
--
[...truncated 508 lines...]
checking whether -pthread is sufficient with -shared... yes
checking for deflate, gzread, gzwrite, inflate in -lz... yes
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating 3rdparty/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
=== configuring in 3rdparty/stout
(/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout)
configure: running /bin/bash
../../../../../3rdparty/libprocess/3rdparty/stout/configure
--disable-option-checking '--prefix=/usr/local' '--disable-java'
'--disable-python' '--disable-webui'
'JAVA_HOME=/home/hudson/tools/java/latest1.6' '--enable-shared=no' '--with-pic'
--cache-file=/dev/null
--srcdir=../../../../../3rdparty/libprocess/3rdparty/stout
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
+ GLOG_v=1
+ MESOS_VERBOSE=1
+ make distcheck
if test -d mesos-0.19.0; then find mesos-0.19.0 -type d ! -perm -200 -exec
chmod u+w {} ';' rm -rf mesos-0.19.0 || { sleep 5 rm -rf
mesos-0.19.0; }; else :; fi
test -d mesos-0.19.0 || mkdir mesos-0.19.0
(cd 3rdparty make top_distdir=../mesos-0.19.0
distdir=../mesos-0.19.0/3rdparty \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[1]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty'
(cd libprocess make top_distdir=../../mesos-0.19.0
distdir=../../mesos-0.19.0/3rdparty/libprocess \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[2]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess'
:
test -d ../../mesos-0.19.0/3rdparty/libprocess || mkdir
../../mesos-0.19.0/3rdparty/libprocess
(cd 3rdparty make top_distdir=../../../mesos-0.19.0
distdir=../../../mesos-0.19.0/3rdparty/libprocess/3rdparty \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[3]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty'
(cd stout make top_distdir=../../../../mesos-0.19.0
distdir=../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[4]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout'
:
test -d ../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout || mkdir
../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout
test -n : \
|| find ../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout
-type d ! -perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/bash
/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/3rdparty/libprocess/3rdparty/stout/install-sh
-c -m a+r {} {} \; \
|| chmod -R a+r
../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout
make[4]: Leaving directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout'
make[3]: Leaving directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty'
test -n : \
|| find ../../mesos-0.19.0/3rdparty/libprocess -type d ! -perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/bash
Re: Review Request 19164: Used new optional envmap parameter to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19164/ --- (Updated April 2, 2014, 1:49 p.m.) Review request for mesos, Ben Mahler and Ian Downes. Changes --- rebased and added dependency Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- see summary. Diffs (updated) - src/slave/containerizer/mesos_containerizer.cpp c819c97d96d232a1de3c1ed2fc848bebf66981f7 src/tests/containerizer_tests.cpp b539070e3f76bb878bd3aeb04da93f25bdcecbeb Diff: https://reviews.apache.org/r/19164/diff/ Testing --- make check. Thanks, Dominic Hamon
[jira] [Created] (MESOS-1180) make distcheck fails with --disable-java
Vinod Kone created MESOS-1180: - Summary: make distcheck fails with --disable-java Key: MESOS-1180 URL: https://issues.apache.org/jira/browse/MESOS-1180 Project: Mesos Issue Type: Bug Components: test Reporter: Vinod Kone Priority: Minor Fix For: 0.19.0 Observed this on Jenkins. https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2033/console ... ... configure: GCC version: 4.6 checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... yes checking for backtrace in -lunwind... no checking whether or not we can build with JNI... /usr/bin/ld: skipping incompatible /home/hudson/tools/java/latest1.6/jre/lib/i386/server/libjvm.so when searching for -ljvm /usr/bin/ld: cannot find -ljvm collect2: ld returned 1 exit status configure: error: failed to build with JNI make: *** [distcheck] Error 1 Build step 'Execute shell' marked build as failure -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui #2033
filed: https://issues.apache.org/jira/browse/MESOS-1180
reverted this build to 'make check' in the interim.
@vinodkone
On Wed, Apr 2, 2014 at 1:49 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
See
https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2033/changes
Changes:
[benjamin.hindman] Added os::environment.
--
[...truncated 508 lines...]
checking whether -pthread is sufficient with -shared... yes
checking for deflate, gzread, gzwrite, inflate in -lz... yes
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... no
checking whether g++ supports C++11 features with -std=c++0x... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating 3rdparty/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
=== configuring in 3rdparty/stout
(/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout)
configure: running /bin/bash
../../../../../3rdparty/libprocess/3rdparty/stout/configure
--disable-option-checking '--prefix=/usr/local' '--disable-java'
'--disable-python' '--disable-webui'
'JAVA_HOME=/home/hudson/tools/java/latest1.6' '--enable-shared=no'
'--with-pic' --cache-file=/dev/null
--srcdir=../../../../../3rdparty/libprocess/3rdparty/stout
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
+ GLOG_v=1
+ MESOS_VERBOSE=1
+ make distcheck
if test -d mesos-0.19.0; then find mesos-0.19.0 -type d ! -perm -200
-exec chmod u+w {} ';' rm -rf mesos-0.19.0 || { sleep 5 rm -rf
mesos-0.19.0; }; else :; fi
test -d mesos-0.19.0 || mkdir mesos-0.19.0
(cd 3rdparty make top_distdir=../mesos-0.19.0
distdir=../mesos-0.19.0/3rdparty \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
make[1]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty'
(cd libprocess make top_distdir=../../mesos-0.19.0
distdir=../../mesos-0.19.0/3rdparty/libprocess \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
make[2]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess'
:
test -d ../../mesos-0.19.0/3rdparty/libprocess || mkdir
../../mesos-0.19.0/3rdparty/libprocess
(cd 3rdparty make top_distdir=../../../mesos-0.19.0
distdir=../../../mesos-0.19.0/3rdparty/libprocess/3rdparty \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
make[3]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty'
(cd stout make top_distdir=../../../../mesos-0.19.0
distdir=../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
make[4]: Entering directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout'
:
test -d ../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout ||
mkdir ../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout
test -n : \
|| find
../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout -type d !
-perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/bash
/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/3rdparty/libprocess/3rdparty/stout/install-sh
-c -m a+r {} {} \; \
|| chmod -R a+r
../../../../mesos-0.19.0/3rdparty/libprocess/3rdparty/stout
make[4]: Leaving directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty/stout'
make[3]: Leaving directory
`/x1/jenkins/jenkins-slave/workspace/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/build/3rdparty/libprocess/3rdparty'
test -n : \
|| find ../../mesos-0.19.0/3rdparty/libprocess -type d ! -perm
-755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d !
[jira] [Commented] (MESOS-1181) Improve cpplint rule coverage
[ https://issues.apache.org/jira/browse/MESOS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958201#comment-13958201 ] Dominic Hamon commented on MESOS-1181: -- We are in sync: https://reviews.apache.org/r/19775/ Improve cpplint rule coverage - Key: MESOS-1181 URL: https://issues.apache.org/jira/browse/MESOS-1181 Project: Mesos Issue Type: Improvement Reporter: Adam B Assignee: Adam B Priority: Minor Labels: lint, style ReviewBot is checking our patches' style for us, and we can check it ourselves with support/mesos-style.py, but there are only a few rules enabled right now. I plan to enable more rules, fixing lint errors as needed. I'd also like to add new style rules for things like single/double line spacing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1182) Implement an output stream operator overload for Master::Slave
Vinod Kone created MESOS-1182: - Summary: Implement an output stream operator overload for Master::Slave Key: MESOS-1182 URL: https://issues.apache.org/jira/browse/MESOS-1182 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Fix For: 0.19.0 There are several places in master.cpp where we print a slave as LOG(INFO) slave-id ( slave-info.hostname() ); Sometimes we also include slave-pid in this message. Sometimes we forgot to include the hostname. It would be much cleaner if we can just do the below everywhere. LOG(INFO) Slave: slave ..; -- This message was sent by Atlassian JIRA (v6.2#6252)
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME #1758
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/1758/ -- [...truncated 148 lines...] Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing bin/gdb-mesos-local.sh Removing bin/gdb-mesos-master.sh Removing bin/gdb-mesos-slave.sh Removing bin/gdb-mesos-tests.sh Removing bin/lldb-mesos-local.sh Removing bin/lldb-mesos-master.sh Removing bin/lldb-mesos-slave.sh Removing bin/lldb-mesos-tests.sh Removing bin/mesos-local-flags.sh Removing bin/mesos-local.sh Removing bin/mesos-master-flags.sh Removing bin/mesos-master.sh Removing bin/mesos-slave-flags.sh Removing bin/mesos-slave.sh Removing bin/mesos-tests-flags.sh Removing bin/mesos-tests.sh Removing bin/mesos.sh Removing bin/valgrind-mesos-local.sh Removing bin/valgrind-mesos-master.sh Removing bin/valgrind-mesos-slave.sh Removing bin/valgrind-mesos-tests.sh Removing config.guess Removing config.log Removing config.lt Removing config.status Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile Removing ec2/Makefile.in Removing include/mesos/mesos.hpp Removing install-sh Removing libtool Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing mesos-0.19.0.tar.gz Removing mesos-0.19.0/ Removing mesos.pc Removing missing Removing mpi/mpiexec-mesos Removing src/.deps/ Removing src/Makefile Removing src/Makefile.in Removing src/cli/.deps/ Removing src/common/.deps/ Removing src/deploy/mesos-daemon.sh Removing src/deploy/mesos-start-cluster.sh Removing src/deploy/mesos-start-masters.sh Removing src/deploy/mesos-start-slaves.sh Removing src/deploy/mesos-stop-cluster.sh Removing src/deploy/mesos-stop-masters.sh Removing src/deploy/mesos-stop-slaves.sh Removing src/examples/.deps/ Removing src/examples/java/test-exception-framework Removing src/examples/java/test-executor Removing src/examples/java/test-framework Removing src/examples/java/test-log Removing src/examples/java/test-multiple-executors-framework Removing src/examples/python/test-executor Removing src/examples/python/test-framework Removing src/exec/.deps/ Removing src/files/.deps/ Removing src/java/generated/org/apache/mesos/MesosNativeLibrary.java Removing src/java/jni/.deps/ Removing src/java/mesos.pom Removing src/jvm/.deps/ Removing src/jvm/org/apache/.deps/ Removing src/launcher/.deps/ Removing src/linux/.deps/ Removing src/local/.deps/ Removing src/log/.deps/ Removing src/log/tool/.deps/ Removing src/logging/.deps/ Removing src/master/.deps/ Removing src/messages/.deps/ Removing src/python/setup.py Removing src/sasl/.deps/ Removing src/sched/.deps/ Removing src/slave/.deps/ Removing src/slave/containerizer/.deps/ Removing src/slave/containerizer/isolators/cgroups/.deps/ Removing src/state/.deps/ Removing src/tests/.deps/ Removing src/zookeeper/.deps/ stderr: warning: failed to remove mesos-0.19.0/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing .libs/ Removing 3rdparty/Makefile Removing 3rdparty/Makefile.in Removing 3rdparty/leveldb/ Removing 3rdparty/libprocess/.deps/ Removing 3rdparty/libprocess/3rdparty/.deps/ Removing 3rdparty/libprocess/3rdparty/Makefile Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/config.log Removing 3rdparty/libprocess/3rdparty/stout/config.status Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.log Removing 3rdparty/libprocess/config.lt Removing 3rdparty/libprocess/config.status Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/libtool Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing bin/gdb-mesos-local.sh Removing bin/gdb-mesos-master.sh Removing bin/gdb-mesos-slave.sh Removing bin/gdb-mesos-tests.sh Removing bin/lldb-mesos-local.sh Removing bin/lldb-mesos-master.sh Removing bin/lldb-mesos-slave.sh Removing bin/lldb-mesos-tests.sh Removing bin/mesos-local-flags.sh Removing
Re: Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- (Updated April 2, 2014, 9:39 p.m.) Review request for mesos, Jie Yu and Vinod Kone. Changes --- Cleaned up sending thread ids from child to test. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs (updated) - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
Review Request 19951: Change cgroups::assign to assign all threads.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19951/ --- Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone. Repository: mesos-git Description --- Use cgroups.proc (rather than tasks) so all threads in the pid's threadgroup are assigned. Documentation/cgroups/cgroups.txt: You can use the cgroup.procs file instead of the tasks file to move all threads in a threadgroup at once. Added a test to verify all threads are assigned. This obviates the recently introduced assignAllThreads and thus it has been removed. Diffs - src/linux/cgroups.hpp 5a5735721fb9f051eee661edb08d1cdaa163d0f3 src/linux/cgroups.cpp 8202c282f580d027a60ded2081962e96e4860f60 src/slave/slave.cpp a356f5f0a0a43581c6380df1bc9b15fd228b3015 src/tests/cgroups_tests.cpp 6ba9de622953e158feadaa9950618b0b13c9e832 src/tests/cluster.hpp 11684d99c6a4e623dd5ff9977d210de59f33f5cd Diff: https://reviews.apache.org/r/19951/diff/ Testing --- make check # Linux Thanks, Ian Downes
[jira] [Updated] (MESOS-1182) Implement an output stream operator overload for Master::Slave
[ https://issues.apache.org/jira/browse/MESOS-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-1182: -- Labels: newbie (was: ) Implement an output stream operator overload for Master::Slave -- Key: MESOS-1182 URL: https://issues.apache.org/jira/browse/MESOS-1182 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Labels: newbie Fix For: 0.19.0 There are several places in master.cpp where we print a slave as LOG(INFO) slave-id ( slave-info.hostname() ); Sometimes we also include slave-pid in this message. Sometimes we forgot to include the hostname. It would be much cleaner if we can just do the below everywhere. LOG(INFO) Slave: slave ..; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1182) Implement an output stream operator overload for Master::Slave
[ https://issues.apache.org/jira/browse/MESOS-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-1182: -- Priority: Minor (was: Major) Implement an output stream operator overload for Master::Slave -- Key: MESOS-1182 URL: https://issues.apache.org/jira/browse/MESOS-1182 Project: Mesos Issue Type: Improvement Reporter: Vinod Kone Priority: Minor Labels: newbie Fix For: 0.19.0 There are several places in master.cpp where we print a slave as LOG(INFO) slave-id ( slave-info.hostname() ); Sometimes we also include slave-pid in this message. Sometimes we forgot to include the hostname. It would be much cleaner if we can just do the below everywhere. LOG(INFO) Slave: slave ..; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1152) ProcTest.MultipleThreads is flaky
[
https://issues.apache.org/jira/browse/MESOS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958215#comment-13958215
]
Ian Downes commented on MESOS-1152:
---
Updated review also cleans up the passing of thread ids from child to test.
ProcTest.MultipleThreads is flaky
-
Key: MESOS-1152
URL: https://issues.apache.org/jira/browse/MESOS-1152
Project: Mesos
Issue Type: Bug
Affects Versions: 0.19.0
Reporter: Vinod Kone
Assignee: Ian Downes
Fix For: 0.19.0
{noformat}
[ RUN ] ProcTest.MultipleThreads
stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 12412 }
Expected: childThreads
Which is: { 152 }
{noformat}
{noformat}
[ RUN ] ProcTest.MultipleThreads
../../../../../mesos/3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:190:
Failure
Value of: (((*(int *) (status))) 0x7f)
Actual: 4
Expected: 9
[ FAILED ] ProcTest.MultipleThreads (1 ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Review Request 19162: Added optional envvar map to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/#review39360 --- Ship it! Great cleanup with os::environment. 3rdparty/libprocess/include/process/subprocess.hpp https://reviews.apache.org/r/19162/#comment71726 Please add a short comment that explains that the environment is combined with the current environment (overriding as necessary) since by default doing an exec*e only uses the environment that one passes. You could even consider adding a TODO to differentiate this case. 3rdparty/libprocess/src/subprocess.cpp https://reviews.apache.org/r/19162/#comment71728 Might as well initialize size to 0 too! 3rdparty/libprocess/src/subprocess.cpp https://reviews.apache.org/r/19162/#comment71722 Minor cleanup, but let's name the constructor argument '_environment' to match style in codebase and then s/environ/environment/ please. 3rdparty/libprocess/src/subprocess.cpp https://reviews.apache.org/r/19162/#comment71724 Won't you get the '\0' copied for free if you copy 'entry.size() + 1' since you did 'entry.c_str()'? 3rdparty/libprocess/src/tests/subprocess_tests.cpp https://reviews.apache.org/r/19162/#comment71729 Newline here please. 3rdparty/libprocess/src/tests/subprocess_tests.cpp https://reviews.apache.org/r/19162/#comment71731 I'm not sure what you mean by override OS but calling this just 'environmentOverride' is probably sufficient. 3rdparty/libprocess/src/tests/subprocess_tests.cpp https://reviews.apache.org/r/19162/#comment71733 // Make sure we override an existing environment variable. os::setenv(MESSAGE, hello); mapstring, string environment; environment[MESSAGE] = goodbye; - Benjamin Hindman On April 2, 2014, 8:44 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated April 2, 2014, 8:44 p.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
[jira] [Created] (MESOS-1184) Support running nested slaves.
Ian Downes created MESOS-1184: - Summary: Support running nested slaves. Key: MESOS-1184 URL: https://issues.apache.org/jira/browse/MESOS-1184 Project: Mesos Issue Type: Task Affects Versions: 0.18.0 Reporter: Ian Downes We should be able to support (perhaps assuming root priviledges) a slave running within a container, i.e., nesting slaves. This could be very useful for testing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1183) Support multiple slaves when using cgroups
Ian Downes created MESOS-1183: - Summary: Support multiple slaves when using cgroups Key: MESOS-1183 URL: https://issues.apache.org/jira/browse/MESOS-1183 Project: Mesos Issue Type: Task Components: isolation Affects Versions: 0.18.0 Reporter: Ian Downes We should be able to run multiple slaves on the same host when cgroups are used. This is used (at least) when running local clusters for testing. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19416: Moved subprocess and cleanup method to new cpp.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/#review39363 --- Ship it! Ship It! - Benjamin Hindman On March 20, 2014, 10:58 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/ --- (Updated March 20, 2014, 10:58 p.m.) Review request for mesos and Ben Mahler. Repository: mesos-git Description --- see summary this is part zero of 19162 which will be rebased to depend on this. Diffs - 3rdparty/libprocess/Makefile.am 3c6219eb6e76306463b3710ab7e50ec8b75d3d76 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION Diff: https://reviews.apache.org/r/19416/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19416: Moved subprocess and cleanup method to new cpp.
On March 19, 2014, 10:15 p.m., Ben Mahler wrote: 3rdparty/libprocess/src/subprocess.cpp, line 13 https://reviews.apache.org/r/19416/diff/1/?file=528343#file528343line13 Now that it's out of the header file, can we pull 'cleanup' out of the 'process' namespace, or is there a reason to keep it in there? Continuing our discussion from the previous review: Anonymous namespaces are, as far as I know, new style in libprocess. Did you need this? Need it? No. But it does make it so that the symbols aren't available outside the translation unit. Ie, I can ensure that noone else is calling cleanup/using Envp so I won't break people inadvertently if I change them. Which case are you concerned about? I don't see how people could be using our 'cleanup' unless they: -Forward declares a 'cleanup' with the same signature, and -Omit a definition for their 'cleanup' declaration. So they unknowingly get our version of cleanup at link-time, rather than a multiple definition linker error. But this seems pretty contrived so I'm not sure if it's the case you were thinking of? I think unnamed namespaces are a reasonably defensive tool. But I'd like to see explicit conversations with committers around new style (as Bernd did for 'explicit' constructors). Once agreed, it would be great to update our code to consistently follow the new style. And at the same time, we should try to strike a balance between high value changes for the project and technical debt cleanup. :) Dominic Hamon wrote: 1. There's no reason to keep cleanup in process, except that it is being compiled as part of process and is visible as an external symbol to other translation units unless it's in a... 2. unnamed namespace. This is less about accidental use and more about someone finding cleanup and trying to use it. I agree that's unlikely in this case, but there are other cases where it is useful and it's become a habit of mine to use it whenever I'm writing a helper method or class in a translation unit that I don't want visible outside that translation unit. We should talk about these more, but it's not exactly high priority. I'll remove it from this CL. Ben Mahler wrote: Sounds good! For what it's worth, while we haven't used anonymous namespaces we have used 'static' some places to limit exposure. - Benjamin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/#review37810 --- On March 20, 2014, 10:58 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/ --- (Updated March 20, 2014, 10:58 p.m.) Review request for mesos and Ben Mahler. Repository: mesos-git Description --- see summary this is part zero of 19162 which will be rebased to depend on this. Diffs - 3rdparty/libprocess/Makefile.am 3c6219eb6e76306463b3710ab7e50ec8b75d3d76 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION Diff: https://reviews.apache.org/r/19416/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19162: Added optional envvar map to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated April 2, 2014, 2:57 p.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Changes --- changed dependency and respond to comments Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs (updated) - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19162: Added optional envvar map to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/#review39362 --- 3rdparty/libprocess/src/subprocess.cpp https://reviews.apache.org/r/19162/#comment71737 true - also switched to strncpy in case there's an embedded NULL. - Dominic Hamon On April 2, 2014, 2:57 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/ --- (Updated April 2, 2014, 2:57 p.m.) Review request for mesos, Benjamin Hindman and Ben Mahler. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- See summary Diffs - 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION 3rdparty/libprocess/src/tests/subprocess_tests.cpp d15d4d159105474117c4ea432b215431209ab539 Diff: https://reviews.apache.org/r/19162/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19416: Moved subprocess and cleanup method to new cpp.
On Wed, Apr 2, 2014 at 2:57 PM, Benjamin Hindman b...@berkeley.edu wrote: On March 19, 2014, 10:15 p.m., Ben Mahler wrote: 3rdparty/libprocess/src/subprocess.cpp, line 13 https://reviews.apache.org/r/19416/diff/1/?file=528343#file528343line13 Now that it's out of the header file, can we pull 'cleanup' out of the 'process' namespace, or is there a reason to keep it in there? Continuing our discussion from the previous review: Anonymous namespaces are, as far as I know, new style in libprocess. Did you need this? Need it? No. But it does make it so that the symbols aren't available outside the translation unit. Ie, I can ensure that noone else is calling cleanup/using Envp so I won't break people inadvertently if I change them. Which case are you concerned about? I don't see how people could be using our 'cleanup' unless they: -Forward declares a 'cleanup' with the same signature, and -Omit a definition for their 'cleanup' declaration. So they unknowingly get our version of cleanup at link-time, rather than a multiple definition linker error. But this seems pretty contrived so I'm not sure if it's the case you were thinking of? I think unnamed namespaces are a reasonably defensive tool. But I'd like to see explicit conversations with committers around new style (as Bernd did for 'explicit' constructors). Once agreed, it would be great to update our code to consistently follow the new style. And at the same time, we should try to strike a balance between high value changes for the project and technical debt cleanup. :) Dominic Hamon wrote: 1. There's no reason to keep cleanup in process, except that it is being compiled as part of process and is visible as an external symbol to other translation units unless it's in a... 2. unnamed namespace. This is less about accidental use and more about someone finding cleanup and trying to use it. I agree that's unlikely in this case, but there are other cases where it is useful and it's become a habit of mine to use it whenever I'm writing a helper method or class in a translation unit that I don't want visible outside that translation unit. We should talk about these more, but it's not exactly high priority. I'll remove it from this CL. Ben Mahler wrote: Sounds good! For what it's worth, while we haven't used anonymous namespaces we have used 'static' some places to limit exposure. There was a time when static was deprecated for that, though it seems to have come back. Un-named namespaces are still useful for defining types that are local to a translation unit. But yes, either works. The former is just my muscle memory still twitching. - Benjamin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/#review37810 --- On March 20, 2014, 10:58 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19416/ --- (Updated March 20, 2014, 10:58 p.m.) Review request for mesos and Ben Mahler. Repository: mesos-git Description --- see summary this is part zero of 19162 which will be rebased to depend on this. Diffs - 3rdparty/libprocess/Makefile.am 3c6219eb6e76306463b3710ab7e50ec8b75d3d76 3rdparty/libprocess/include/process/subprocess.hpp 75b2a96b3ca62a4a59e64aba046f1d797bd8ebf6 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION Diff: https://reviews.apache.org/r/19416/diff/ Testing --- make check Thanks, Dominic Hamon
Re: Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/#review39365 --- 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp https://reviews.apache.org/r/19952/#comment71744 'thread' might cause you problems in c++11. consider threadId - Dominic Hamon On April 2, 2014, 2:39 p.m., Ian Downes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- (Updated April 2, 2014, 2:39 p.m.) Review request for mesos, Benjamin Hindman, Jie Yu, and Vinod Kone. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
Re: Review Request 19952: Reduce stack size for threads in proc tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19952/ --- (Updated April 2, 2014, 10:05 p.m.) Review request for mesos, Benjamin Hindman, Jie Yu, and Vinod Kone. Changes --- Added BenH. Bugs: MESOS-1152 https://issues.apache.org/jira/browse/MESOS-1152 Repository: mesos-git Description --- See summary. Diffs - 3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp cb2b6007928eef4b9b1f488b630d96565624185e Diff: https://reviews.apache.org/r/19952/diff/ Testing --- make check # Linux Thanks, Ian Downes
[jira] [Assigned] (MESOS-95) Add performance tests
[ https://issues.apache.org/jira/browse/MESOS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yan Xu reassigned MESOS-95: --- Assignee: Yan Xu Add performance tests - Key: MESOS-95 URL: https://issues.apache.org/jira/browse/MESOS-95 Project: Mesos Issue Type: Task Components: test Reporter: Charles Reiss Assignee: Yan Xu Priority: Minor Labels: performance, test There should be performance tests (especially of the master) so we can tell when new features introduce performance regressions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1185) Reorganize cgroup layout
Ian Downes created MESOS-1185:
-
Summary: Reorganize cgroup layout
Key: MESOS-1185
URL: https://issues.apache.org/jira/browse/MESOS-1185
Project: Mesos
Issue Type: Task
Components: isolation
Affects Versions: 0.17.0, 0.18.0
Reporter: Ian Downes
Fix For: 0.19.0
The proposed layout has the following advantages:
1. Easier breakdown of accounting (and isolation) of resources
2. Support multiple slaves (MESOS-1183)
3. Support nesting slaves (MESOS-1184)
Using the default values of the relevant flags and the cpu controller
MESOS_CGROUPS_HIERARCHY = /sys/fs/cgroup
MESOS_CGROUPS_ROOT = mesos
each slave would have a separate cgroup:
{noformat}
/sys/fs/cgroup/cpu/mesos/{SlaveID}
{noformat}
Under the slave's cgroup there would be a 'slave' cgroup which would contain
the slave process (and child processes like mesos-fetcher)
{noformat}
/sys/fs/cgroup/cpu/mesos/{SlaveID}/slave
{noformat}
And a 'containers' cgroup which would contain all containers as child cgroups
{noformat}
/sys/fs/cgroup/cpu/mesos/{SlaveID}/containers/{ContainerID}
{noformat}
Multiple slaves would be differentiated by their SlaveIDs.
Nested slaves would have an extended MESOS_CGROUP_ROOT which contained the
parent's SlaveID.
Such a layout would enable answering resource usage questions like:
1. Total usage of all slaves
2. Total usage of a single slave
3. Usage of a slave process
4. Total usage of all containers of a slave
5. Usage of a particular container (what we have now)
And also setting limits to any of the above.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MESOS-1183) Support multiple slaves when using cgroups
[ https://issues.apache.org/jira/browse/MESOS-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Downes updated MESOS-1183: -- Fix Version/s: 0.19.0 Support multiple slaves when using cgroups -- Key: MESOS-1183 URL: https://issues.apache.org/jira/browse/MESOS-1183 Project: Mesos Issue Type: Task Components: isolation Affects Versions: 0.18.0 Reporter: Ian Downes Fix For: 0.19.0 We should be able to run multiple slaves on the same host when cgroups are used. This is used (at least) when running local clusters for testing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1184) Support running nested slaves.
[ https://issues.apache.org/jira/browse/MESOS-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Downes updated MESOS-1184: -- Fix Version/s: 0.19.0 Support running nested slaves. -- Key: MESOS-1184 URL: https://issues.apache.org/jira/browse/MESOS-1184 Project: Mesos Issue Type: Task Affects Versions: 0.18.0 Reporter: Ian Downes Fix For: 0.19.0 We should be able to support (perhaps assuming root priviledges) a slave running within a container, i.e., nesting slaves. This could be very useful for testing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[ https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Hamon resolved MESOS-995. - Resolution: Fixed Fix Version/s: 0.19.0 Extend Subprocess to support environment variables, changing user and working directory --- Key: MESOS-995 URL: https://issues.apache.org/jira/browse/MESOS-995 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Ian Downes Assignee: Dominic Hamon Priority: Minor Fix For: 0.19.0 These are frequently needed so we should support them in Subprocess. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19164: Used new optional envmap parameter to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19164/ --- (Updated April 2, 2014, 3:15 p.m.) Review request for mesos, Ben Mahler and Ian Downes. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- see summary. Diffs (updated) - src/slave/containerizer/mesos_containerizer.cpp c819c97d96d232a1de3c1ed2fc848bebf66981f7 src/tests/containerizer_tests.cpp b539070e3f76bb878bd3aeb04da93f25bdcecbeb Diff: https://reviews.apache.org/r/19164/diff/ Testing --- make check. Thanks, Dominic Hamon
[jira] [Commented] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[ https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958249#comment-13958249 ] Dominic Hamon commented on MESOS-995: - commit 653462ccdf771cac0ee41c5377fb64e005a9fc19 Author: Dominic Hamon dha...@twopensource.com Date: Wed Apr 2 15:06:05 2014 -0700 Added optional environment map to subprocess. Review: https://reviews.apache.org/r/19162 Extend Subprocess to support environment variables, changing user and working directory --- Key: MESOS-995 URL: https://issues.apache.org/jira/browse/MESOS-995 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Ian Downes Assignee: Dominic Hamon Priority: Minor Fix For: 0.19.0 These are frequently needed so we should support them in Subprocess. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19951: Change cgroups::assign to assign all threads.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19951/#review39368 --- Bad patch! Reviews applied: [19951] Failed command: make -j3 check GTEST_FILTER='' /dev/null Error: ev.c:1531:31: warning: 'ev_default_loop_ptr' initialized and declared 'extern' [enabled by default] ev.c: In function 'evpipe_write': ev.c:2160:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] ev.c:2172:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] ev.c: In function 'pipecb': ev.c:2193:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] ev.c:2207:16: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] In file included from /usr/include/c++/4.6/ext/hash_set:61:0, from src/glog/stl_logging.h:54, from src/stl_logging_unittest.cc:34: /usr/include/c++/4.6/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] In file included from src/utilities.h:73:0, from src/googletest.h:38, from src/stl_logging_unittest.cc:48: src/base/mutex.h:137:0: warning: _XOPEN_SOURCE redefined [enabled by default] /usr/include/features.h:166:0: note: this is the location of the previous definition warning: no files found matching 'Makefile' under directory 'docs' warning: no files found matching 'indexsidebar.html' under directory 'docs' zip_safe flag not set; analyzing archive contents... WARNING: '.' not a valid package name; please use only.-separated package names in setup.py package init file 'src/__init__.py' not found (or not a regular file) cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/ObjC but not for C++ [enabled by default] zip_safe flag not set; analyzing archive contents... Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. In file included from ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:47:0, from ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46, from ../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58, from tests/cgroups_tests.cpp:36: ../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include/gtest/gtest.h: In function 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1, const T2) [with T1 = long unsigned int, T2 = long int]': ../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include/gtest/gtest.h:1353:30: instantiated from 'static testing::AssertionResult testing::internal::EqHelperlhs_is_null_literal::Compare(const char*, const char*, const T1, const T2) [with T1 = long unsigned int, T2 = long int, bool lhs_is_null_literal = false]' tests/cgroups_tests.cpp:870:3: instantiated from here ../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include/gtest/gtest.h:1316:3: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] cc1plus: all warnings being treated as errors make[3]: *** [tests/mesos_tests-cgroups_tests.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [check-am] Error 2 make[1]: *** [check] Error 2 make: *** [check-recursive] Error 1 - Mesos ReviewBot On April 2, 2014, 9:42 p.m., Ian Downes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19951/ --- (Updated April 2, 2014, 9:42 p.m.) Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone. Repository: mesos-git Description --- Use cgroups.proc (rather than tasks) so all threads in the pid's threadgroup are assigned. Documentation/cgroups/cgroups.txt: You can use
[jira] [Commented] (MESOS-1181) Improve cpplint rule coverage
[ https://issues.apache.org/jira/browse/MESOS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958287#comment-13958287 ] Adam B commented on MESOS-1181: --- Here's the current error count for the inactive_rules from Dominic's review (minus build/include_alpha which has 0): build/header_guard - 450 build/include - 6 build/include_order - 1443 build/include_what_you_use - 187 build/namespaces - 201 build/storage_class - 14 legal/copyright - 209 readability/braces - 9 readability/casting - 165 readability/check - 40 readability/function - 16 readability/namespace - 606 readability/streams - 62 readability/todo - 5 runtime/arrays - 3 runtime/explicit - 64 runtime/int - 140 runtime/printf - 7 runtime/references - 41 runtime/string - 13 runtime/threadsafe_fn - 9 whitespace/blank_line - 4 whitespace/braces - 3723 whitespace/comments - 1559 whitespace/empty_loop_body - 44 whitespace/end_of_line - 6 whitespace/indent - 723 whitespace/line_length - 111 whitespace/newline - 2 whitespace/operators - 5 whitespace/parens - 552 whitespace/semicolon - 1 Improve cpplint rule coverage - Key: MESOS-1181 URL: https://issues.apache.org/jira/browse/MESOS-1181 Project: Mesos Issue Type: Improvement Reporter: Adam B Assignee: Adam B Priority: Minor Labels: lint, style ReviewBot is checking our patches' style for us, and we can check it ourselves with support/mesos-style.py, but there are only a few rules enabled right now. I plan to enable more rules, fixing lint errors as needed. I'd also like to add new style rules for things like single/double line spacing. -- This message was sent by Atlassian JIRA (v6.2#6252)
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME #1759
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/1759/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision 653462ccdf771cac0ee41c5377fb64e005a9fc19 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui #2034
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2034/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision 653462ccdf771cac0ee41c5377fb64e005a9fc19 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME #2037
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME/2037/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision 653462ccdf771cac0ee41c5377fb64e005a9fc19 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui #2035
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2035/ -- Started by an SCM change Building remotely on ubuntu3 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision 653462ccdf771cac0ee41c5377fb64e005a9fc19 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at
[jira] [Commented] (MESOS-570) Generate Javadocs
[ https://issues.apache.org/jira/browse/MESOS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958318#comment-13958318 ] Dave Lester commented on MESOS-570: --- I assume that changing the current directory name to latest is fine -- that will continue the url pattern used by our documentation urls (/documentation/latest/) Generate Javadocs - Key: MESOS-570 URL: https://issues.apache.org/jira/browse/MESOS-570 Project: Mesos Issue Type: Sub-task Reporter: Dave Lester Assignee: Tobi Knaup Attachments: javadoc.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19164: Used new optional envmap parameter to subprocess.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19164/#review39372 --- Patch looks great! Reviews applied: [19164] All tests passed. - Mesos ReviewBot On April 2, 2014, 10:15 p.m., Dominic Hamon wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19164/ --- (Updated April 2, 2014, 10:15 p.m.) Review request for mesos, Ben Mahler and Ian Downes. Bugs: MESOS-995 https://issues.apache.org/jira/browse/MESOS-995 Repository: mesos-git Description --- see summary. Diffs - src/slave/containerizer/mesos_containerizer.cpp c819c97d96d232a1de3c1ed2fc848bebf66981f7 src/tests/containerizer_tests.cpp b539070e3f76bb878bd3aeb04da93f25bdcecbeb Diff: https://reviews.apache.org/r/19164/diff/ Testing --- make check. Thanks, Dominic Hamon
Review Request 19965: Enabled whitespace/semicolon rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19965/ --- Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/semicolon rule for cpplint, which covers the following logic: # You should always have a space after a semicolon # except for few corner cases # You shouldn't have a space before a semicolon at the end of the line. # There's a special case for for since the style guide allows space before # the semicolon there. Also cleaning up a mesos-style.py comment, and enabling build/include_alpha, which seems to pass for me. Diffs - src/tests/cgroups_tests.cpp 6ba9de6 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19965/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/semicolon enabled. Thanks, Adam B
[jira] [Commented] (MESOS-1181) Improve cpplint rule coverage
[ https://issues.apache.org/jira/browse/MESOS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958327#comment-13958327 ] Adam B commented on MESOS-1181: --- Enabling whitespace/semicolon: https://reviews.apache.org/r/19965/ Improve cpplint rule coverage - Key: MESOS-1181 URL: https://issues.apache.org/jira/browse/MESOS-1181 Project: Mesos Issue Type: Improvement Reporter: Adam B Assignee: Adam B Priority: Minor Labels: lint, style ReviewBot is checking our patches' style for us, and we can check it ourselves with support/mesos-style.py, but there are only a few rules enabled right now. I plan to enable more rules, fixing lint errors as needed. I'd also like to add new style rules for things like single/double line spacing. -- This message was sent by Atlassian JIRA (v6.2#6252)
Review Request 19966: Enabled whitespace/blank_line rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19966/ --- Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/blank_line rule for cpplint, which covers the following: 'Redundant blank line at the start of a code block ' 'should be deleted.' 'Redundant blank line at the end of a code block ' 'should be deleted.' 'Do not leave a blank line after public|protected|private:' 'class|struct: should be preceded by a blank line' Diffs - src/common/resources.cpp 61c5bda src/slave/slave.cpp a356f5f src/tests/cluster.hpp 11684d9 src/tests/mesos.hpp f77fbfe support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19966/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/blank_line enabled. Thanks, Adam B
[jira] [Resolved] (MESOS-570) Generate Javadocs
[ https://issues.apache.org/jira/browse/MESOS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Lester resolved MESOS-570. --- Resolution: Fixed Now online: http://mesos.apache.org/api/current/java/, applying Tobi's patch with the minor change I suggested. Generate Javadocs - Key: MESOS-570 URL: https://issues.apache.org/jira/browse/MESOS-570 Project: Mesos Issue Type: Sub-task Reporter: Dave Lester Assignee: Tobi Knaup Attachments: javadoc.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-570) Generate Javadocs
[ https://issues.apache.org/jira/browse/MESOS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958354#comment-13958354 ] Vinod Kone commented on MESOS-570: -- This is awesome! Thanks for the work Tobi and Dave. Generate Javadocs - Key: MESOS-570 URL: https://issues.apache.org/jira/browse/MESOS-570 Project: Mesos Issue Type: Sub-task Reporter: Dave Lester Assignee: Tobi Knaup Attachments: javadoc.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
Review Request 19967: Enabled whitespace/operators rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19967/ --- Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/operators rule for cpplint, which covers the following: 'Missing spaces around =' # You should always have whitespace around binary operators. # Check = and = first to avoid false positives with and , then # check non-include lines for spacing around and . # We allow no-spaces around when used like this: 1020, but # not otherwise (particularly, not when used as streams) # Also ignore using ns::operator; 'Missing spaces around ' 'Missing spaces around ' # There shouldn't be space around unary operators Diffs - 3rdparty/libprocess/include/process/pid.hpp fbd512f src/common/type_utils.hpp 784a808 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19967/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/operators enabled. Thanks, Adam B
Re: Review Request 19967: Enabled whitespace/operators rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19967/#review39375 --- 3rdparty/libprocess/include/process/pid.hpp https://reviews.apache.org/r/19967/#comment71764 Alternatively, we could try to teach cpplint.py to ignore this warning if '!' follows 'operator', to handle operator overloading cases like this. - Adam B On April 2, 2014, 4:54 p.m., Adam B wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19967/ --- (Updated April 2, 2014, 4:54 p.m.) Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/operators rule for cpplint, which covers the following: 'Missing spaces around =' # You should always have whitespace around binary operators. # Check = and = first to avoid false positives with and , then # check non-include lines for spacing around and . # We allow no-spaces around when used like this: 1020, but # not otherwise (particularly, not when used as streams) # Also ignore using ns::operator; 'Missing spaces around ' 'Missing spaces around ' # There shouldn't be space around unary operators Diffs - 3rdparty/libprocess/include/process/pid.hpp fbd512f src/common/type_utils.hpp 784a808 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19967/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/operators enabled. Thanks, Adam B
[jira] [Comment Edited] (MESOS-570) Generate Javadocs
[ https://issues.apache.org/jira/browse/MESOS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958347#comment-13958347 ] Dave Lester edited comment on MESOS-570 at 4/2/14 11:57 PM: Now online: http://mesos.apache.org/api/latest/java/, applying Tobi's patch with the minor change I suggested. was (Author: davelester): Now online: http://mesos.apache.org/api/current/java/, applying Tobi's patch with the minor change I suggested. Generate Javadocs - Key: MESOS-570 URL: https://issues.apache.org/jira/browse/MESOS-570 Project: Mesos Issue Type: Sub-task Reporter: Dave Lester Assignee: Tobi Knaup Attachments: javadoc.diff -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19965: Enabled whitespace/semicolon rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19965/#review39376 --- Patch looks great! Reviews applied: [19775, 19965] All tests passed. - Mesos ReviewBot On April 2, 2014, 11:26 p.m., Adam B wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19965/ --- (Updated April 2, 2014, 11:26 p.m.) Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/semicolon rule for cpplint, which covers the following logic: # You should always have a space after a semicolon # except for few corner cases # You shouldn't have a space before a semicolon at the end of the line. # There's a special case for for since the style guide allows space before # the semicolon there. Also cleaning up a mesos-style.py comment, and enabling build/include_alpha, which seems to pass for me. Diffs - src/tests/cgroups_tests.cpp 6ba9de6 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19965/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/semicolon enabled. Thanks, Adam B
Review Request 19968: Enabled whitespace/end_of_line rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19968/ --- Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/end_of_line rule for cpplint, which covers the following: 'Line ends in whitespace. Consider deleting these extra spaces.' Diffs - 3rdparty/libprocess/src/decoder.hpp 88da57f 3rdparty/libprocess/src/httpd.cpp 4f4ab1b 3rdparty/libprocess/src/process.cpp 9654c04 src/common/date_utils.hpp 085c1ce src/common/factory.hpp 94056f6 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19968/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/end_of_line enabled. Thanks, Adam B
[jira] [Commented] (MESOS-1181) Improve cpplint rule coverage
[ https://issues.apache.org/jira/browse/MESOS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958365#comment-13958365 ] Adam B commented on MESOS-1181: --- whitespace/blank_line: https://reviews.apache.org/r/19966/ whitespace/operators: https://reviews.apache.org/r/19967/ whitespace/end_of_line: https://reviews.apache.org/r/19968/ Improve cpplint rule coverage - Key: MESOS-1181 URL: https://issues.apache.org/jira/browse/MESOS-1181 Project: Mesos Issue Type: Improvement Reporter: Adam B Assignee: Adam B Priority: Minor Labels: lint, style ReviewBot is checking our patches' style for us, and we can check it ourselves with support/mesos-style.py, but there are only a few rules enabled right now. I plan to enable more rules, fixing lint errors as needed. I'd also like to add new style rules for things like single/double line spacing. -- This message was sent by Atlassian JIRA (v6.2#6252)
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME #2038
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME/2038/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu3 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-JAVA_HOME/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision d83f9f98c5f568859f02b8245787335efdfe7871 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4 Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/ Removing 3rdparty/libprocess/3rdparty/stout/configure Removing 3rdparty/libprocess/3rdparty/stout/missing Removing 3rdparty/libprocess/Makefile.in Removing 3rdparty/libprocess/aclocal.m4 Removing 3rdparty/libprocess/ar-lib Removing 3rdparty/libprocess/autom4te.cache/ Removing 3rdparty/libprocess/config.guess Removing 3rdparty/libprocess/config.sub Removing 3rdparty/libprocess/configure Removing 3rdparty/libprocess/depcomp Removing 3rdparty/libprocess/ltmain.sh Removing 3rdparty/libprocess/m4/libtool.m4 Removing 3rdparty/libprocess/m4/ltoptions.m4 Removing 3rdparty/libprocess/m4/ltsugar.m4 Removing 3rdparty/libprocess/m4/ltversion.m4 Removing 3rdparty/libprocess/m4/lt~obsolete.m4 Removing 3rdparty/libprocess/missing Removing Makefile.in Removing aclocal.m4 Removing ar-lib Removing autom4te.cache/ Removing build/ Removing config.guess Removing config.sub Removing configure Removing depcomp Removing ec2/Makefile.in Removing install-sh Removing ltmain.sh Removing m4/libtool.m4 Removing m4/ltoptions.m4 Removing m4/ltsugar.m4 Removing m4/ltversion.m4 Removing m4/lt~obsolete.m4 Removing missing Removing src/Makefile.in stderr: warning: failed to remove build/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at
[jira] [Commented] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[
https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958383#comment-13958383
]
Bhuvan Arumugam commented on MESOS-995:
---
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
Extend Subprocess to support environment variables, changing user and working
directory
---
Key: MESOS-995
URL: https://issues.apache.org/jira/browse/MESOS-995
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Ian Downes
Assignee: Dominic Hamon
Priority: Minor
Fix For: 0.19.0
These are frequently needed so we should support them in Subprocess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[
https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958383#comment-13958383
]
Bhuvan Arumugam edited comment on MESOS-995 at 4/3/14 12:35 AM:
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
```
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
```
was (Author: bhuvan):
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
Extend Subprocess to support environment variables, changing user and working
directory
---
Key: MESOS-995
URL: https://issues.apache.org/jira/browse/MESOS-995
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Ian Downes
Assignee: Dominic Hamon
Priority: Minor
Fix For: 0.19.0
These are frequently needed so we should support them in Subprocess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[
https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958383#comment-13958383
]
Bhuvan Arumugam edited comment on MESOS-995 at 4/3/14 12:37 AM:
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
{code}
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
{code}
was (Author: bhuvan):
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
{{{
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
}}}
Extend Subprocess to support environment variables, changing user and working
directory
---
Key: MESOS-995
URL: https://issues.apache.org/jira/browse/MESOS-995
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Ian Downes
Assignee: Dominic Hamon
Priority: Minor
Fix For: 0.19.0
These are frequently needed so we should support them in Subprocess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[
https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958383#comment-13958383
]
Bhuvan Arumugam edited comment on MESOS-995 at 4/3/14 12:36 AM:
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
{{
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
}}
was (Author: bhuvan):
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
```
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
```
Extend Subprocess to support environment variables, changing user and working
directory
---
Key: MESOS-995
URL: https://issues.apache.org/jira/browse/MESOS-995
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Ian Downes
Assignee: Dominic Hamon
Priority: Minor
Fix For: 0.19.0
These are frequently needed so we should support them in Subprocess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (MESOS-995) Extend Subprocess to support environment variables, changing user and working directory
[
https://issues.apache.org/jira/browse/MESOS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958383#comment-13958383
]
Bhuvan Arumugam edited comment on MESOS-995 at 4/3/14 12:36 AM:
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
{{{
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
}}}
was (Author: bhuvan):
It seem to break unit tests, osTest and ProcTest. Let me know if I should
upload verbose log output, if it isn't obvious.
{{
$ make check -j3
.
.
[ RUN ] ProcTest.MultipleThreads
../../../../3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp:181: Failure
Value of: (procThreads).get()
Actual: { 10050, 10053 }
Expected: childThreads
Which is: { 0 }
[ FAILED ] ProcTest.MultipleThreads (2 ms)
.
.
[ RUN ] OsTest.children
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:361: Failure
Value of: children.get().size()
Actual: 1
Expected: 0u
Which is: 0
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:379: Failure
Value of: children.get().size()
Actual: 2
Expected: 1u
Which is: 1
[ FAILED ] OsTest.children (31 ms)
[ RUN ] OsTest.process
[ OK ] OsTest.process (0 ms)
[ RUN ] OsTest.processes
[ OK ] OsTest.processes (11 ms)
[ RUN ] OsTest.killtree
[ OK ] OsTest.killtree (64 ms)
[ RUN ] OsTest.pstree
../../../../3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp:604: Failure
Value of: tree.get().children.size()
Actual: 1
Expected: 0u
Which is: 0
-+- 10048 ./stout-tests
\--- 10050 ()
[ FAILED ] OsTest.pstree (21 ms)
.
.
[--] Global test environment tear-down
[==] 118 tests from 24 test cases ran. (480 ms total)
[ PASSED ] 115 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] ProcTest.MultipleThreads
[ FAILED ] OsTest.children
[ FAILED ] OsTest.pstree
}}
Extend Subprocess to support environment variables, changing user and working
directory
---
Key: MESOS-995
URL: https://issues.apache.org/jira/browse/MESOS-995
Project: Mesos
Issue Type: Improvement
Components: libprocess
Reporter: Ian Downes
Assignee: Dominic Hamon
Priority: Minor
Fix For: 0.19.0
These are frequently needed so we should support them in Subprocess.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Review Request 19968: Enabled whitespace/end_of_line rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19968/#review39379 --- Patch looks great! Reviews applied: [19775, 19968] All tests passed. - Mesos ReviewBot On April 3, 2014, 12:06 a.m., Adam B wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19968/ --- (Updated April 3, 2014, 12:06 a.m.) Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/end_of_line rule for cpplint, which covers the following: 'Line ends in whitespace. Consider deleting these extra spaces.' Diffs - 3rdparty/libprocess/src/decoder.hpp 88da57f 3rdparty/libprocess/src/httpd.cpp 4f4ab1b 3rdparty/libprocess/src/process.cpp 9654c04 src/common/date_utils.hpp 085c1ce src/common/factory.hpp 94056f6 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19968/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/end_of_line enabled. Thanks, Adam B
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui #2036
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/2036/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disable-Java-Disable-Python-Disable-Webui/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision d83f9f98c5f568859f02b8245787335efdfe7871 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing build/ stderr: warning: failed to remove build/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing build/ stderr: warning: failed to remove build/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)
Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME #1760
See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/1760/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision d83f9f98c5f568859f02b8245787335efdfe7871 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)
Re: Review Request 19795: Changed Executor::info to executor info future.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19795/#review39335 --- src/slave/slave.hpp https://reviews.apache.org/r/19795/#comment71686 I think this is leaking too much implementation detail? How about just saying // Schedules __runTask() once the executor is launched. src/slave/slave.hpp https://reviews.apache.org/r/19795/#comment71689 How about: Is called when the executor info is ready. src/slave/slave.hpp https://reviews.apache.org/r/19795/#comment71723 It just seems a bit confusing to have this static method in this struct when we have a id variable. How about pulling this up to Master class? src/slave/slave.hpp https://reviews.apache.org/r/19795/#comment71690 s/not be/not/ src/slave/slave.hpp https://reviews.apache.org/r/19795/#comment71691 s/is ready/will be ready/ src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71692 not in alphabetical order. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71694 Instead of constructing and passing the message why not do the message construction in _doReliableRegistration()? That way you would avoid any nasty races. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71721 s/Driver/driver/ src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71725 Pull this inside the if below. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71727 put .onAny on the new line. executor-info .onAny(defer(..., ...)); src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71746 Do we need this future passed through considering we have the executorInfo member variable? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71734 log the executor id. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71732 Why did you move this down to here? If a framework goes to TERMINATING before __runTask() gets called, the framework would never be removed. This should be below line #991. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71735 ditto. formatting. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71747 ditto. Do we need this future passed through considering we have the executorInfo member variable? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71736 log the task. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71738 I don't think the slave can be in RECOVERING state here? Also, do we want to proceed if the slave is TERMINATING? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71745 CHECK_NOTNULL(executor); src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71739 ditto. formatting. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71748 ditto. Do we need this future passed through considering we have the executorInfo member variable? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71741 I don't think slave can be in RECOVERING state here. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71742 log the executor. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71743 CHECK_NOTNULL(executor); src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71756 Log that we are shutting this down. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71758 formatting. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71761 ditto. do we need to pass the future? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71760 Can this be in any other state than RECOVERING? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71774 Why is this returning a Future? Is this for future proofing (no pun intended). src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71762 This seems to be a weird failure message. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71775 quotes around executor ids. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71776 No need to extract this into a method (see my comments later). src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71777 this formatting is different from others. src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71769 Do you want to address this TODO now? I'm afraid that if you only make ExecutorInfo a future when we revisit this TODO we have to go through the same pain of refactoring? src/slave/slave.cpp https://reviews.apache.org/r/19795/#comment71770 In fact I think even the directory should be
Re: Build failed in Jenkins: Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME #1760
aargh. 'make distcheck' creates a directory without write permissions, which means git clean -fdx doesn't work :/ i'll fix this shortly. sorry for the noise. On Wed, Apr 2, 2014 at 5:41 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/1760/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on ubuntu5 (Ubuntu ubuntu) in workspace https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git Checking out Revision d83f9f98c5f568859f02b8245787335efdfe7871 (origin/master) Cleaning workspace Resetting working tree FATAL: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ hudson.plugins.git.GitException: Command git clean -fdx returned status code 1: stdout: Removing 3rdparty/leveldb/ Removing mesos-0.19.0/ stderr: warning: failed to remove mesos-0.19.0/ at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1183) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1160) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1156) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:972) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:982) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:410) at hudson.plugins.git.GitAPI.clean(GitAPI.java:253) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)
Re: Review Request 19967: Enabled whitespace/operators rule for cpplint.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19967/#review39382 --- Patch looks great! Reviews applied: [19775, 19967] All tests passed. - Mesos ReviewBot On April 2, 2014, 11:54 p.m., Adam B wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19967/ --- (Updated April 2, 2014, 11:54 p.m.) Review request for mesos and Dominic Hamon. Bugs: MESOS-1181 https://issues.apache.org/jira/browse/MESOS-1181 Repository: mesos-git Description --- Enabled whitespace/operators rule for cpplint, which covers the following: 'Missing spaces around =' # You should always have whitespace around binary operators. # Check = and = first to avoid false positives with and , then # check non-include lines for spacing around and . # We allow no-spaces around when used like this: 1020, but # not otherwise (particularly, not when used as streams) # Also ignore using ns::operator; 'Missing spaces around ' 'Missing spaces around ' # There shouldn't be space around unary operators Diffs - 3rdparty/libprocess/include/process/pid.hpp fbd512f src/common/type_utils.hpp 784a808 support/mesos-style.py edd41f926d6df30513f8fa6c928960e6495af70a Diff: https://reviews.apache.org/r/19967/diff/ Testing --- Ran mesos-style.py over entire source base with whitespace/operators enabled. Thanks, Adam B
[jira] [Created] (MESOS-1187) precision errors with allocation calculations
aniruddha sathaye created MESOS-1187: Summary: precision errors with allocation calculations Key: MESOS-1187 URL: https://issues.apache.org/jira/browse/MESOS-1187 Project: Mesos Issue Type: Bug Components: allocation, master Reporter: aniruddha sathaye Priority: Minor As allocations are stored/transmitted as doubles many a times precision errors creep in. we have seen erroneous share calculations happen only because of floating point arithmetic. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 17567: Added External Containerizer.
On March 31, 2014, 8:03 p.m., Vinod Kone wrote: src/slave/containerizer/external_containerizer.cpp, lines 293-295 https://reviews.apache.org/r/17567/diff/15/?file=531801#file531801line293 This seems a bit unfortunate. How about creating a protobuf that wraps all the arguments that are needed for launch (and other methods) and passing it on to the external containerizer? Packed this into ExternalTask which wraps TaskInfo and the mesos-executor path. On March 31, 2014, 8:03 p.m., Vinod Kone wrote: src/slave/containerizer/external_containerizer.cpp, lines 1125-1126 https://reviews.apache.org/r/17567/diff/15/?file=531801#file531801line1125 Instead of closing the file descriptor, how about just writing the length of the protobuf first and then serialized protobuf. That way the read end could know the exact size of data to read. This is how we do serialization and deserialization of protobufs to files. See protobuf::write() and protobuf::read(). Till Toenshoff wrote: I like this approach. Will play with this a bit to see if there is something we are missing. Now implemented that in the latest revision. On March 31, 2014, 8:03 p.m., Vinod Kone wrote: src/slave/containerizer/external_containerizer.cpp, line 1135 https://reviews.apache.org/r/17567/diff/15/?file=531801#file531801line1135 If we do the above and if we have MESOS-995, can you just leverage subprocess here? Till Toenshoff wrote: Almost, yes. Let me quote from the header: // TODO(tillt): Remove and use process::subprocess once that has // become flexible enough to support all features needed: // - in-child-context commands (chdir) after fork and before exec. // - direct execution without the invocation of /bin/sh. // - external ownership of pipe file descriptors. Additionally, we are missing a setsid within the child-context to prevent a slave suicide once the external containerizer process gets terminated. For the reasoning: chdir() is clear and would be covered by MESOS-995, which is great. Direct execution is needed as we currently are depending on proper pipe close escalation. If /bin/sh is used to invoke and when its child process is closing a pipe, the shell has to close its end as well. In some tests I did, I found out that this is not always happening, depending on the shell in use - specifically dash on ubuntu appears to not do that in certain configurations. External ownership of the pipe handles is needed as the current way of signaling a complete transmission of those protobufs is done via detection of an EOF. Subprocess assumes to have full control and does assume the pipes to be open until the process terminates. Now circling back to your earlier comment on prepending the protobufs by their size to signal a complete transmission. That might ease the process as we could remove the need for direct execution and external pipe ownership. So the only remaining reason to not use subprocess then would be the missing setsid(). So now we are only missing setsid() to fully rely upon subprocess. Will propose an overload as soon as I addressed all other comments. - Till --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/#review38504 --- On April 2, 2014, 2:02 a.m., Till Toenshoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/ --- (Updated April 2, 2014, 2:02 a.m.) Review request for mesos, Ian Downes, Niklas Nielsen, and Vinod Kone. Bugs: MESOS-816 https://issues.apache.org/jira/browse/MESOS-816 Repository: mesos-git Description --- This patch adds the so-called external containerizer. This containerizer delegates all containerizer calls directly to an external containerizer program (which can be specified on start-up). Few calls have internal fall-back implementations such as wait(), destroy() and usage(). The protocol for the interactions with the external program is as follows: COMMAND (ADDITIONAL-PARAMETERS) INPUT-PROTO RESULT-PROTO launch (ContainerID, --mesos-executor, path) TaskInfo ExternalStatus update (ContainerID) ResourceArray ExternalStatus usage (ContainerID) ResourceStatistics wait (ContainerID) ExternalTermination destroy (ContainerID) ExternalStatus When protocol buffers need to be provided, the Mesos side of the external containerizer implementation will serialize the protos on stdin and vice-versa for reading protos on stdout as drafted in the above scheme. NOTE: This is
