[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Add duplicate agent flags

2016-04-19 Thread Jay Guo (JIRA) 

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

Jay Guo commented on MESOS-3781:


OK, let's revisit deprecation implementation when it's done. Thx!

> Replace Master/Slave Terminology Phase I - Add duplicate agent flags 
> -
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Commented] (MESOS-5234) Add helper function to simplify tokenize handling

2016-04-19 Thread Klaus Ma (JIRA) 

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

Klaus Ma commented on MESOS-5234:
-

RR: https://reviews.apache.org/r/46425/

> Add helper function to simplify tokenize handling
> -
>
> Key: MESOS-5234
> URL: https://issues.apache.org/jira/browse/MESOS-5234
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>Priority: Minor
>
> Based on [~jvanremoortere]'s suggestion on patch of MESOS-4627, it's better 
> to add a helper function 
> {code}
> foreachtoken(temp, ",\n", [](const string& token) { ... });
> {code}
>  to simplify {{tokenize()}} handling.



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

[jira] [Commented] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Jan Schlicht (JIRA) 

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

Jan Schlicht commented on MESOS-5236:
-

In these configurations the kernel modules is loaded and it's not tested inside 
a docker container.
I followed the example in 
http://askubuntu.com/questions/699565/example-overlayfs-usage to confirm that 
it works. It did with Ubuntu 14.04, not sure about 12.04, will try that again 
later.

> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness
> -
>
> Key: MESOS-5236
> URL: https://issues.apache.org/jira/browse/MESOS-5236
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>  Labels: flaky, flaky-test, mesosphere
>
> Observed on internal Mesosphere CI:
> {noformat}
> [13:31:06] : [Step 10/10] [ RUN  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
> [13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
> Provisioning image rootfs with overlayfs: 
> 'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
> ch/rootfs/workdir'
> [13:31:06] : [Step 10/10] 
> ../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
> [13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
> layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
> '/tmp/Dkgh5V/rootfs' with overlayfs: No such device
> [13:31:06] : [Step 10/10] [  FAILED  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
> {noformat}



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

[jira] [Commented] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Shuai Lin (JIRA) 

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

Shuai Lin commented on MESOS-5236:
--

[~nfnt] It's not likely a configuration problem, because there is a test filter 
that would disable overlay related tests when it detects overlayfs is not 
supported, that's what would happen when the overlay kernel module is not 
loaded.

After some googling I found a similar issue 
[here|https://github.com/coreos/rkt/issues/1537], which is caused by "overlay 
over overlay". It could happen If the tests is running inside a docker 
container, and the docker storage driver happens to be overlayfs. 

[~neilc] can you confirm it?


> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness
> -
>
> Key: MESOS-5236
> URL: https://issues.apache.org/jira/browse/MESOS-5236
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>  Labels: flaky, flaky-test, mesosphere
>
> Observed on internal Mesosphere CI:
> {noformat}
> [13:31:06] : [Step 10/10] [ RUN  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
> [13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
> Provisioning image rootfs with overlayfs: 
> 'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
> ch/rootfs/workdir'
> [13:31:06] : [Step 10/10] 
> ../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
> [13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
> layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
> '/tmp/Dkgh5V/rootfs' with overlayfs: No such device
> [13:31:06] : [Step 10/10] [  FAILED  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
> {noformat}



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

[jira] [Assigned] (MESOS-5237) The windows version of `os::access` has differing behavior than the POSIX version.

2016-04-19 Thread Michael Park (JIRA) 

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

Michael Park reassigned MESOS-5237:
---

Assignee: Michael Park

> The windows version of `os::access` has differing behavior than the POSIX 
> version.
> --
>
> Key: MESOS-5237
> URL: https://issues.apache.org/jira/browse/MESOS-5237
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Michael Park
>Assignee: Michael Park
>  Labels: mesosphere,, windows
>
> The POSIX version of {{os::access}} looks like this:
> {code}
> inline Try access(const std::string& path, int how)
> {
>   if (::access(path.c_str(), how) < 0) {
> if (errno == EACCES) {
>   return false;
> } else {
>   return ErrnoError();
> }
>   }
>   return true;
> }
> {code}
> Compare this to the Windows version of {{os::access}} which looks like this 
> following:
> {code}
> inline Try access(const std::string& fileName, int how)
> {
>   if (::_access(fileName.c_str(), how) != 0) {
> return ErrnoError("access: Could not access path '" + fileName + "'");
>   }
>   return true;
> }
> {code}
> As we can see, the case where {{errno}} is set to {{EACCES}} is handled 
> differently between the 2 functions.
> We can actually consolidate the 2 functions by simply using the POSIX 
> version. The challenge is that on POSIX, we should use {{::access}} and 
> {{_::access}} on Windows. Note however, that this problem is already solved, 
> as we have an implementation of {{::access}} for Windows in 
> {{3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp}} which simply 
> defers to {{::_access}}.
> Thus, I propose to simply consolidate the 2 implementations.



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

[jira] [Created] (MESOS-5237) The windows version of `os::access` has differing behavior than the POSIX version.

2016-04-19 Thread Michael Park (JIRA) 
Michael Park created MESOS-5237:
---

 Summary: The windows version of `os::access` has differing 
behavior than the POSIX version.
 Key: MESOS-5237
 URL: https://issues.apache.org/jira/browse/MESOS-5237
 Project: Mesos
  Issue Type: Bug
  Components: stout
Reporter: Michael Park


The POSIX version of {{os::access}} looks like this:

{code}
inline Try access(const std::string& path, int how)
{
  if (::access(path.c_str(), how) < 0) {
if (errno == EACCES) {
  return false;
} else {
  return ErrnoError();
}
  }
  return true;
}
{code}

Compare this to the Windows version of {{os::access}} which looks like this 
following:

{code}
inline Try access(const std::string& fileName, int how)
{
  if (::_access(fileName.c_str(), how) != 0) {
return ErrnoError("access: Could not access path '" + fileName + "'");
  }

  return true;
}
{code}

As we can see, the case where {{errno}} is set to {{EACCES}} is handled 
differently between the 2 functions.

We can actually consolidate the 2 functions by simply using the POSIX version. 
The challenge is that on POSIX, we should use {{::access}} and {{_::access}} on 
Windows. Note however, that this problem is already solved, as we have an 
implementation of {{::access}} for Windows in 
{{3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp}} which simply 
defers to {{::_access}}.

Thus, I propose to simply consolidate the 2 implementations.



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

[jira] [Assigned] (MESOS-5017) Don't consider agents without allocatable resources in the allocator

2016-04-19 Thread Klaus Ma (JIRA) 

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

Klaus Ma reassigned MESOS-5017:
---

Assignee: Klaus Ma

> Don't consider agents without allocatable resources in the allocator
> 
>
> Key: MESOS-5017
> URL: https://issues.apache.org/jira/browse/MESOS-5017
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Dario Rexin
>Assignee: Klaus Ma
>Priority: Minor
>
> In the DRFAllocator we don't check if an agent has allocatable resources 
> until we try to offer the resources to a framework. We could already filter 
> them out at the beginning. 



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

[jira] [Commented] (MESOS-3781) Replace Master/Slave Terminology Phase I - Add duplicate agent flags

2016-04-19 Thread Vinod Kone (JIRA) 

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

Vinod Kone commented on MESOS-3781:
---

Let me work on adding multiple name support to flags and then you can base your 
deprecation patch based on that.

> Replace Master/Slave Terminology Phase I - Add duplicate agent flags 
> -
>
> Key: MESOS-3781
> URL: https://issues.apache.org/jira/browse/MESOS-3781
> Project: Mesos
>  Issue Type: Task
>Reporter: Diana Arroyo
>Assignee: Jay Guo
>




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

[jira] [Comment Edited] (MESOS-5174) Update the balloon-framework to run on test clusters

2016-04-19 Thread Joseph Wu (JIRA) 

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

Joseph Wu edited comment on MESOS-5174 at 4/19/16 9:40 PM:
---

|| Review || Summary ||
| https://reviews.apache.org/r/46407/ | Balloon executor changes | 
| https://reviews.apache.org/r/45604/ | First 3 bullet points in the 
description |
| https://reviews.apache.org/r/46411/ | Terminal status updates | 
| https://reviews.apache.org/r/45905/ | Metrics | 


was (Author: kaysoky):
|| Review || Summary ||
| https://reviews.apache.org/r/45604/ | First 4 bullet points in the 
description |
| https://reviews.apache.org/r/45905/ | Metrics | 

> Update the balloon-framework to run on test clusters
> 
>
> Key: MESOS-5174
> URL: https://issues.apache.org/jira/browse/MESOS-5174
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, technical debt
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere, tech-debt
>
> There are a couple of problems with the balloon framework that prevent it 
> from being deployed (easily) on an actual cluster:
> * The framework accepts 100% of memory in an offer.  This means the expected 
> behavior (finish or OOM) is dependent on the offer size.
> * The framework assumes the {{balloon-executor}} binary is available on each 
> agent.  This is generally only true in the build environment or in 
> single-agent test environments.
> * The framework does not specify CPUs with the executor.  This is required by 
> many isolators.
> * The executor's {{TASK_FINISHED}} logic path was untested and is flaky.
> * The framework has no metrics.
> * The framework only launches a single task and then exits.  With this 
> behavior, we can't have useful metrics.



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

[jira] [Commented] (MESOS-5060) Requesting /files/read.json with a negative length value causes subsequent /files requests to 404.

2016-04-19 Thread Greg Mann (JIRA) 

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

Greg Mann commented on MESOS-5060:
--

Hi [~dongdong], thanks for the patch! Sorry that I didn't get back to you about 
your design yesterday.

I would propose the following: let's first get a patch merged which just fixes 
the bug, and then we can consider how to best implement the semantics that we 
would like for the {{/read}} endpoint. That way, we can fix the bug ASAP and 
then take some time to get the new behavior right.

There is currently a design doc in progress which will be introducing a 
versioned operator HTTP API (MESOS-4791), so it's possible that we could wait 
to implement the new semantics until that work is implemented. Then, we could 
also avoid introducing breaking changes into the existing {{/read}} endpoint.

I've made a couple comments in your existing patch; would you mind posting 
another patch which only fixes the existing bug (along with a test that 
verifies the bug is fixed)?

Thanks!! :-)

> Requesting /files/read.json with a negative length value causes subsequent 
> /files requests to 404.
> --
>
> Key: MESOS-5060
> URL: https://issues.apache.org/jira/browse/MESOS-5060
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.23.0
> Environment: Mesos 0.23.0 on CentOS 6, also Mesos 0.28.0 on OSX
>Reporter: Tom Petr
>Assignee: zhou xing
>Priority: Minor
> Fix For: 0.29.0
>
>
> I accidentally hit a slave's /files/read.json endpoint with a negative length 
> (ex. http://hostname:5051/files/read.json?path=XXX=0=-100). The 
> HTTP request timed out after 30 seconds with nothing relevant in the slave 
> logs, and subsequent calls to any of the /files endpoints on that slave 
> immediately returned a HTTP 404 response. We ultimately got things working 
> again by restarting the mesos-slave process (checkpointing FTW!), but it'd be 
> wise to guard against negative lengths on the slave's end too.



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

[jira] [Commented] (MESOS-5139) ProvisionerDockerLocalStoreTest.LocalStoreTestWithTar is flaky

2016-04-19 Thread Gilbert Song (JIRA) 

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

Gilbert Song commented on MESOS-5139:
-

Yes, I am also thinking either use `command::tar` or deprecate this test case.

> ProvisionerDockerLocalStoreTest.LocalStoreTestWithTar is flaky
> --
>
> Key: MESOS-5139
> URL: https://issues.apache.org/jira/browse/MESOS-5139
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.28.0
> Environment: Ubuntu14.04
>Reporter: Vinod Kone
>Assignee: Gilbert Song
>  Labels: mesosphere
>
> Found this on ASF CI while testing 0.28.1-rc2
> {code}
> [ RUN  ] ProvisionerDockerLocalStoreTest.LocalStoreTestWithTar
> E0406 18:29:30.870481   520 shell.hpp:93] Command 'hadoop version 2>&1' 
> failed; this is the output:
> sh: 1: hadoop: not found
> E0406 18:29:30.870576   520 fetcher.cpp:59] Failed to create URI fetcher 
> plugin 'hadoop': Failed to create HDFS client: Failed to execute 'hadoop 
> version 2>&1'; the command was either not found or exited with a non-zero 
> exit status: 127
> I0406 18:29:30.871052   520 local_puller.cpp:90] Creating local puller with 
> docker registry '/tmp/3l8ZBv/images'
> I0406 18:29:30.873325   539 metadata_manager.cpp:159] Looking for image 'abc'
> I0406 18:29:30.874438   539 local_puller.cpp:142] Untarring image 'abc' from 
> '/tmp/3l8ZBv/images/abc.tar' to '/tmp/3l8ZBv/store/staging/5tw8bD'
> I0406 18:29:30.901916   547 local_puller.cpp:162] The repositories JSON file 
> for image 'abc' is '{"abc":{"latest":"456"}}'
> I0406 18:29:30.902304   547 local_puller.cpp:290] Extracting layer tar ball 
> '/tmp/3l8ZBv/store/staging/5tw8bD/123/layer.tar to rootfs 
> '/tmp/3l8ZBv/store/staging/5tw8bD/123/rootfs'
> I0406 18:29:30.909144   547 local_puller.cpp:290] Extracting layer tar ball 
> '/tmp/3l8ZBv/store/staging/5tw8bD/456/layer.tar to rootfs 
> '/tmp/3l8ZBv/store/staging/5tw8bD/456/rootfs'
> ../../src/tests/containerizer/provisioner_docker_tests.cpp:183: Failure
> (imageInfo).failure(): Collect failed: Subprocess 'tar, tar, -x, -f, 
> /tmp/3l8ZBv/store/staging/5tw8bD/456/layer.tar, -C, 
> /tmp/3l8ZBv/store/staging/5tw8bD/456/rootfs' failed: tar: This does not look 
> like a tar archive
> tar: Exiting with failure status due to previous errors
> [  FAILED  ] ProvisionerDockerLocalStoreTest.LocalStoreTestWithTar (243 ms)
> {code}



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

[jira] [Commented] (MESOS-5013) Add docker volume driver isolator for Mesos containerizer.

2016-04-19 Thread Jie Yu (JIRA) 

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

Jie Yu commented on MESOS-5013:
---

commit fc3c67b2f326fe7798b416daaf3606377bbc0983
Author: Guangya Liu 
Date:   Tue Apr 19 10:35:19 2016 -0700

Ignored volumes with source in linux filesystem isolator.

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

> Add docker volume driver isolator for Mesos containerizer.
> --
>
> Key: MESOS-5013
> URL: https://issues.apache.org/jira/browse/MESOS-5013
> Project: Mesos
>  Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Guangya Liu
>  Labels: mesosphere
>
> The isolator will interact with Docker Volume Driver Plugins to mount and 
> unmount external volumes to container.



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

[jira] [Commented] (MESOS-5017) Don't consider agents without allocatable resources in the allocator

2016-04-19 Thread Dario Rexin (JIRA) 

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

Dario Rexin commented on MESOS-5017:


I unassigned myself for now, as I will not have time to work on this in the 
near future.

> Don't consider agents without allocatable resources in the allocator
> 
>
> Key: MESOS-5017
> URL: https://issues.apache.org/jira/browse/MESOS-5017
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Dario Rexin
>Priority: Minor
>
> In the DRFAllocator we don't check if an agent has allocatable resources 
> until we try to offer the resources to a framework. We could already filter 
> them out at the beginning. 



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

[jira] [Assigned] (MESOS-5017) Don't consider agents without allocatable resources in the allocator

2016-04-19 Thread Dario Rexin (JIRA) 

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

Dario Rexin reassigned MESOS-5017:
--

Assignee: (was: Dario Rexin)

> Don't consider agents without allocatable resources in the allocator
> 
>
> Key: MESOS-5017
> URL: https://issues.apache.org/jira/browse/MESOS-5017
> Project: Mesos
>  Issue Type: Improvement
>  Components: allocation
>Reporter: Dario Rexin
>Priority: Minor
>
> In the DRFAllocator we don't check if an agent has allocatable resources 
> until we try to offer the resources to a framework. We could already filter 
> them out at the beginning. 



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

[jira] [Commented] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Jan Schlicht (JIRA) 

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

Jan Schlicht commented on MESOS-5236:
-

It's probably a configuration issue. After reading some {{overlay}} related 
docs for Ubuntu it seems that the overlayroot isn't properly configured.

> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness
> -
>
> Key: MESOS-5236
> URL: https://issues.apache.org/jira/browse/MESOS-5236
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>  Labels: flaky, flaky-test, mesosphere
>
> Observed on internal Mesosphere CI:
> {noformat}
> [13:31:06] : [Step 10/10] [ RUN  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
> [13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
> Provisioning image rootfs with overlayfs: 
> 'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
> ch/rootfs/workdir'
> [13:31:06] : [Step 10/10] 
> ../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
> [13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
> layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
> '/tmp/Dkgh5V/rootfs' with overlayfs: No such device
> [13:31:06] : [Step 10/10] [  FAILED  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
> {noformat}



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

[jira] [Commented] (MESOS-1802) HealthCheckTest.HealthStatusChange is flaky on jenkins.

2016-04-19 Thread haosdent (JIRA) 

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

haosdent commented on MESOS-1802:
-

According to another flaky log provided by [~neilc] (Thanks a lot!)
{code}
[ RUN  ] HealthCheckTest.HealthStatusChange
I0420 00:33:12.691145 15381 cluster.cpp:149] Creating default 'local' authorizer
I0420 00:33:12.691897 15381 leveldb.cpp:174] Opened db in 620608ns
I0420 00:33:12.692211 15381 leveldb.cpp:181] Compacted db in 283038ns
I0420 00:33:12.692265 15381 leveldb.cpp:196] Created db iterator in 15184ns
I0420 00:33:12.692273 15381 leveldb.cpp:202] Seeked to beginning of db in 2161ns
I0420 00:33:12.692281 15381 leveldb.cpp:271] Iterated through 0 keys in the db 
in 1084ns
I0420 00:33:12.692312 15381 replica.cpp:779] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I0420 00:33:12.693172 15398 recover.cpp:447] Starting replica recovery
I0420 00:33:12.693435 15400 recover.cpp:473] Replica is in EMPTY status
I0420 00:33:12.695106 15400 replica.cpp:673] Replica in EMPTY status received a 
broadcasted recover request from (3755)@10.0.2.15:41408
I0420 00:33:12.695829 15400 recover.cpp:193] Received a recover response from a 
replica in EMPTY status
I0420 00:33:12.696321 15398 recover.cpp:564] Updating replica status to STARTING
I0420 00:33:12.696807 15402 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 101090ns
I0420 00:33:12.696836 15402 replica.cpp:320] Persisted replica status to 
STARTING
I0420 00:33:12.696964 15402 recover.cpp:473] Replica is in STARTING status
I0420 00:33:12.697968 15400 replica.cpp:673] Replica in STARTING status 
received a broadcasted recover request from (3756)@10.0.2.15:41408
I0420 00:33:12.698274 15400 recover.cpp:193] Received a recover response from a 
replica in STARTING status
I0420 00:33:12.698691 15400 recover.cpp:564] Updating replica status to VOTING
I0420 00:33:12.698882 15400 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 62549ns
I0420 00:33:12.698938 15400 replica.cpp:320] Persisted replica status to VOTING
I0420 00:33:12.699002 15400 recover.cpp:578] Successfully joined the Paxos group
I0420 00:33:12.699128 15400 recover.cpp:462] Recover process terminated
I0420 00:33:12.721339 15401 master.cpp:382] Master 
7cf5923c-3d03-4ed6-826a-efa97f54e765 (archlinux.vagrant.vm) started on 
10.0.2.15:41408
I0420 00:33:12.721387 15401 master.cpp:384] Flags at startup: --acls="" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_http="true" 
--authenticate_http_frameworks="true" --authenticate_slaves="true" 
--authenticators="crammd5" --authorizers="local" 
--credentials="/tmp/9zoT36/credentials" --framework_sorter="drf" --help="false" 
--hostname_lookup="true" --http_authenticators="basic" 
--http_framework_authenticators="basic" --initialize_driver_logging="true" 
--log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO" 
--max_completed_frameworks="50" --max_completed_tasks_per_framework="1000" 
--max_slave_ping_timeouts="5" --quiet="false" 
--recovery_slave_removal_limit="100%" --registry="replicated_log" 
--registry_fetch_timeout="1mins" --registry_store_timeout="100secs" 
--registry_strict="true" --root_submissions="true" 
--slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
--user_sorter="drf" --version="false" 
--webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/9zoT36/master" 
--zk_session_timeout="10secs"
I0420 00:33:12.721667 15401 master.cpp:433] Master only allowing authenticated 
frameworks to register
I0420 00:33:12.721736 15401 master.cpp:439] Master only allowing authenticated 
agents to register
I0420 00:33:12.721745 15401 master.cpp:445] Master only allowing authenticated 
HTTP frameworks to register
I0420 00:33:12.721750 15401 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/9zoT36/credentials'
I0420 00:33:12.722005 15401 master.cpp:489] Using default 'crammd5' 
authenticator
I0420 00:33:12.723206 15401 master.cpp:560] Using default 'basic' HTTP 
authenticator
I0420 00:33:12.723458 15401 master.cpp:640] Using default 'basic' HTTP 
framework authenticator
I0420 00:33:12.723574 15401 master.cpp:687] Authorization enabled
I0420 00:33:12.725332 15399 master.cpp:1932] The newly elected leader is 
master@10.0.2.15:41408 with id 7cf5923c-3d03-4ed6-826a-efa97f54e765
I0420 00:33:12.725376 15399 master.cpp:1945] Elected as the leading master!
I0420 00:33:12.725389 15399 master.cpp:1632] Recovering from registrar
I0420 00:33:12.725544 15399 registrar.cpp:331] Recovering registrar
I0420 00:33:12.726506 15399 log.cpp:524] Attempting to start the writer
I0420 00:33:12.727424 15399 replica.cpp:493] Replica received implicit promise 
request from (3759)@10.0.2.15:41408 with proposal 1
I0420 00:33:12.727517 15399 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 50404ns
I0420

[jira] [Updated] (MESOS-4902) Add authentication to libprocess endpoints

2016-04-19 Thread Greg Mann (JIRA) 

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

Greg Mann updated MESOS-4902:
-
Shepherd: Kapil Arya  (was: Adam B)

> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
>  Issue Type: Improvement
>  Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> * {{/system/stats.json}}
> Adding HTTP authentication to these endpoints is a bit more complicated 
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



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

[jira] [Updated] (MESOS-4951) Enable actors to pass an authentication realm to libprocess

2016-04-19 Thread Greg Mann (JIRA) 

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

Greg Mann updated MESOS-4951:
-
Shepherd: Kapil Arya  (was: Adam B)

> Enable actors to pass an authentication realm to libprocess
> ---
>
> Key: MESOS-4951
> URL: https://issues.apache.org/jira/browse/MESOS-4951
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess, slave
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> To prepare for MESOS-4902, the Mesos master and agent need a way to pass the 
> desired authentication realm to libprocess. Since some endpoints (like 
> {{/profiler/*}}) get installed in libprocess, the master/agent should be able 
> to specify during initialization what authentication realm the 
> libprocess-level endpoints will be authenticated under.



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

[jira] [Updated] (MESOS-4279) Graceful restart of docker task

2016-04-19 Thread Alexander Rukletsov (JIRA) 

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

Alexander Rukletsov updated MESOS-4279:
---
Shepherd: Alexander Rukletsov  (was: Timothy Chen)

> Graceful restart of docker task
> ---
>
> Key: MESOS-4279
> URL: https://issues.apache.org/jira/browse/MESOS-4279
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.2
>Reporter: Martin Bydzovsky
>Assignee: Qian Zhang
>  Labels: docker, mesosphere
>
> I'm implementing a graceful restarts of our mesos-marathon-docker setup and I 
> came to a following issue:
> (it was already discussed on 
> https://github.com/mesosphere/marathon/issues/2876 and guys form mesosphere 
> got to a point that its probably a docker containerizer problem...)
> To sum it up:
> When i deploy simple python script to all mesos-slaves:
> {code}
> #!/usr/bin/python
> from time import sleep
> import signal
> import sys
> import datetime
> def sigterm_handler(_signo, _stack_frame):
> print "got %i" % _signo
> print datetime.datetime.now().time()
> sys.stdout.flush()
> sleep(2)
> print datetime.datetime.now().time()
> print "ending"
> sys.stdout.flush()
> sys.exit(0)
> signal.signal(signal.SIGTERM, sigterm_handler)
> signal.signal(signal.SIGINT, sigterm_handler)
> try:
> print "Hello"
> i = 0
> while True:
> i += 1
> print datetime.datetime.now().time()
> print "Iteration #%i" % i
> sys.stdout.flush()
> sleep(1)
> finally:
> print "Goodbye"
> {code}
> and I run it through Marathon like
> {code:javascript}
> data = {
>   args: ["/tmp/script.py"],
>   instances: 1,
>   cpus: 0.1,
>   mem: 256,
>   id: "marathon-test-api"
> }
> {code}
> During the app restart I get expected result - the task receives sigterm and 
> dies peacefully (during my script-specified 2 seconds period)
> But when i wrap this python script in a docker:
> {code}
> FROM node:4.2
> RUN mkdir /app
> ADD . /app
> WORKDIR /app
> ENTRYPOINT []
> {code}
> and run appropriate application by Marathon:
> {code:javascript}
> data = {
>   args: ["./script.py"],
>   container: {
>   type: "DOCKER",
>   docker: {
>   image: "bydga/marathon-test-api"
>   },
>   forcePullImage: yes
>   },
>   cpus: 0.1,
>   mem: 256,
>   instances: 1,
>   id: "marathon-test-api"
> }
> {code}
> The task during restart (issued from marathon) dies immediately without 
> having a chance to do any cleanup.



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

[jira] [Commented] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Jan Schlicht (JIRA) 

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

Jan Schlicht commented on MESOS-5236:
-

It seems to only affect Ubuntu 12.04 and 14.04. Because {{overlay}} isn't 
enabled there by default, it may be a configuration problem. {{overlay}} was 
enabled by making sure the module is autoload during boot.

> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness
> -
>
> Key: MESOS-5236
> URL: https://issues.apache.org/jira/browse/MESOS-5236
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>  Labels: flaky, flaky-test, mesosphere
>
> Observed on internal Mesosphere CI:
> {noformat}
> [13:31:06] : [Step 10/10] [ RUN  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
> [13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
> Provisioning image rootfs with overlayfs: 
> 'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
> ch/rootfs/workdir'
> [13:31:06] : [Step 10/10] 
> ../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
> [13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
> layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
> '/tmp/Dkgh5V/rootfs' with overlayfs: No such device
> [13:31:06] : [Step 10/10] [  FAILED  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
> {noformat}



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

[jira] [Commented] (MESOS-4279) Graceful restart of docker task

2016-04-19 Thread Alexander Rukletsov (JIRA) 

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

Alexander Rukletsov commented on MESOS-4279:


I would love to, if [~tnachen] has no cycles to do it.

> Graceful restart of docker task
> ---
>
> Key: MESOS-4279
> URL: https://issues.apache.org/jira/browse/MESOS-4279
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.2
>Reporter: Martin Bydzovsky
>Assignee: Qian Zhang
>  Labels: docker, mesosphere
>
> I'm implementing a graceful restarts of our mesos-marathon-docker setup and I 
> came to a following issue:
> (it was already discussed on 
> https://github.com/mesosphere/marathon/issues/2876 and guys form mesosphere 
> got to a point that its probably a docker containerizer problem...)
> To sum it up:
> When i deploy simple python script to all mesos-slaves:
> {code}
> #!/usr/bin/python
> from time import sleep
> import signal
> import sys
> import datetime
> def sigterm_handler(_signo, _stack_frame):
> print "got %i" % _signo
> print datetime.datetime.now().time()
> sys.stdout.flush()
> sleep(2)
> print datetime.datetime.now().time()
> print "ending"
> sys.stdout.flush()
> sys.exit(0)
> signal.signal(signal.SIGTERM, sigterm_handler)
> signal.signal(signal.SIGINT, sigterm_handler)
> try:
> print "Hello"
> i = 0
> while True:
> i += 1
> print datetime.datetime.now().time()
> print "Iteration #%i" % i
> sys.stdout.flush()
> sleep(1)
> finally:
> print "Goodbye"
> {code}
> and I run it through Marathon like
> {code:javascript}
> data = {
>   args: ["/tmp/script.py"],
>   instances: 1,
>   cpus: 0.1,
>   mem: 256,
>   id: "marathon-test-api"
> }
> {code}
> During the app restart I get expected result - the task receives sigterm and 
> dies peacefully (during my script-specified 2 seconds period)
> But when i wrap this python script in a docker:
> {code}
> FROM node:4.2
> RUN mkdir /app
> ADD . /app
> WORKDIR /app
> ENTRYPOINT []
> {code}
> and run appropriate application by Marathon:
> {code:javascript}
> data = {
>   args: ["./script.py"],
>   container: {
>   type: "DOCKER",
>   docker: {
>   image: "bydga/marathon-test-api"
>   },
>   forcePullImage: yes
>   },
>   cpus: 0.1,
>   mem: 256,
>   instances: 1,
>   id: "marathon-test-api"
> }
> {code}
> The task during restart (issued from marathon) dies immediately without 
> having a chance to do any cleanup.



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

[jira] [Commented] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Neil Conway (JIRA) 

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

Neil Conway commented on MESOS-5236:


cc [~jieyu] [~lins05] -- any thoughts on whether this is a legitimate issue or 
a test/environment misconfiguration?

> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness
> -
>
> Key: MESOS-5236
> URL: https://issues.apache.org/jira/browse/MESOS-5236
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>  Labels: flaky, flaky-test, mesosphere
>
> Observed on internal Mesosphere CI:
> {noformat}
> [13:31:06] : [Step 10/10] [ RUN  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
> [13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
> Provisioning image rootfs with overlayfs: 
> 'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
> ch/rootfs/workdir'
> [13:31:06] : [Step 10/10] 
> ../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
> [13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
> layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
> '/tmp/Dkgh5V/rootfs' with overlayfs: No such device
> [13:31:06] : [Step 10/10] [  FAILED  ] 
> OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
> {noformat}



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

[jira] [Created] (MESOS-5236) OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test flakiness

2016-04-19 Thread Neil Conway (JIRA) 
Neil Conway created MESOS-5236:
--

 Summary: OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend test 
flakiness
 Key: MESOS-5236
 URL: https://issues.apache.org/jira/browse/MESOS-5236
 Project: Mesos
  Issue Type: Bug
Reporter: Neil Conway


Observed on internal Mesosphere CI:

{noformat}
[13:31:06] : [Step 10/10] [ RUN  ] 
OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend
[13:31:06]W: [Step 10/10] I0419 13:31:06.708961 23289 overlay.cpp:161] 
Provisioning image rootfs with overlayfs: 
'lowerdir=/tmp/Dkgh5V/source2:/tmp/Dkgh5V/source1,upperdir=/tmp/Dkgh5V/scratch/rootfs/upperdir,workdir=/tmp/Dkgh5V/scrat\
ch/rootfs/workdir'
[13:31:06] : [Step 10/10] 
../../src/tests/containerizer/provisioner_backend_tests.cpp:97: Failure
[13:31:06] : [Step 10/10] (backends["overlay"]->provision( {layer1, 
layer2}, rootfs, sandbox.get())).failure(): Failed to mount rootfs 
'/tmp/Dkgh5V/rootfs' with overlayfs: No such device
[13:31:06] : [Step 10/10] [  FAILED  ] 
OverlayBackendTest.ROOT_OVERLAYFS_OverlayFSBackend (5 ms)
{noformat}



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

[jira] [Commented] (MESOS-1837) failed to determine cgroup for the 'cpu' subsystem

2016-04-19 Thread Martin Tapp (JIRA) 

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

Martin Tapp commented on MESOS-1837:


[~haosdent] Thanks for the info. I noticed this is randomly appearing in logs 
when a task gets killed.

> failed to determine cgroup for the 'cpu' subsystem
> --
>
> Key: MESOS-1837
> URL: https://issues.apache.org/jira/browse/MESOS-1837
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.20.1
> Environment: Ubuntu 14.04
>Reporter: Chris Fortier
>Assignee: Timothy Chen
>
> Attempting to launch Docker container with Marathon. Container is launched 
> then fails. 
> A search of /var/log/syslog reveals:
> Sep 27 03:01:43 vagrant-ubuntu-trusty-64 mesos-slave[1409]: E0927 
> 03:01:43.546957  1463 slave.cpp:2205] Failed to update resources for 
> container 8c2429d9-f090-4443-8108-0206ca37f3fd of executor 
> hello-world.970dbe74-45f2-11e4-8b1d-56847afe9799 running task 
> hello-world.970dbe74-45f2-11e4-8b1d-56847afe9799 on status update for 
> terminal task, destroying container: Failed to determine cgroup for the 'cpu' 
> subsystem: Failed to read /proc/9792/cgroup: Failed to open file 
> '/proc/9792/cgroup': No such file or directory



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

[jira] [Created] (MESOS-5235) Add clang-tidy check catching default branch when switching over enum values

2016-04-19 Thread Benjamin Bannier (JIRA) 
Benjamin Bannier created MESOS-5235:
---

 Summary: Add clang-tidy check catching default branch when 
switching over enum values
 Key: MESOS-5235
 URL: https://issues.apache.org/jira/browse/MESOS-5235
 Project: Mesos
  Issue Type: Improvement
Reporter: Benjamin Bannier


{{Enum}} values have a limited domain which allows compilers to emit 
diagnostics if not all possible values are handled in {{switch}} statements. 
Adding {[default}} branches interferes with these compiler checks as a 
{{default}} branch would always match.

We try to avoid {{default}} branches in {{switch}} statements over enum values, 
and should add a static analysis check to catch any such instances.

This should be an easier starter check to implement since it should be possible 
to implement all the matching with {{clang-tidy}} matchers.



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

[jira] [Created] (MESOS-5234) Add helper function to simplify tokenize handling

2016-04-19 Thread Klaus Ma (JIRA) 
Klaus Ma created MESOS-5234:
---

 Summary: Add helper function to simplify tokenize handling
 Key: MESOS-5234
 URL: https://issues.apache.org/jira/browse/MESOS-5234
 Project: Mesos
  Issue Type: Bug
  Components: stout
Reporter: Klaus Ma
Assignee: Klaus Ma
Priority: Minor


Based on [~jvanremoortere]'s suggestion on patch of MESOS-4627, it's better to 
add a helper function {{foreachtoken(temp, ",\n", [](const string& token) { ... 
});}} to simplify {{tokenize()}} handling.



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

[jira] [Updated] (MESOS-5234) Add helper function to simplify tokenize handling

2016-04-19 Thread Klaus Ma (JIRA) 

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

Klaus Ma updated MESOS-5234:

Description: 
Based on [~jvanremoortere]'s suggestion on patch of MESOS-4627, it's better to 
add a helper function 
{code}
foreachtoken(temp, ",\n", [](const string& token) { ... });
{code}
 to simplify {{tokenize()}} handling.

  was:Based on [~jvanremoortere]'s suggestion on patch of MESOS-4627, it's 
better to add a helper function {{foreachtoken(temp, ",\n", [](const string& 
token) { ... });}} to simplify {{tokenize()}} handling.


> Add helper function to simplify tokenize handling
> -
>
> Key: MESOS-5234
> URL: https://issues.apache.org/jira/browse/MESOS-5234
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>Priority: Minor
>
> Based on [~jvanremoortere]'s suggestion on patch of MESOS-4627, it's better 
> to add a helper function 
> {code}
> foreachtoken(temp, ",\n", [](const string& token) { ... });
> {code}
>  to simplify {{tokenize()}} handling.



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

[jira] [Comment Edited] (MESOS-5060) Requesting /files/read.json with a negative length value causes subsequent /files requests to 404.

2016-04-19 Thread zhou xing (JIRA) 

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

zhou xing edited comment on MESOS-5060 at 4/19/16 8:09 AM:
---

[~greggomann] and [~bmahler], I submitted a draft review request based on my 
previous comments, if you have any comments, please let me know, thanks.

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


was (Author: dongdong):
[~greggomann] and [~bmahler], I submitted a draft review request based on my 
previous comments, if you have any comments, please let me know, thanks.

> Requesting /files/read.json with a negative length value causes subsequent 
> /files requests to 404.
> --
>
> Key: MESOS-5060
> URL: https://issues.apache.org/jira/browse/MESOS-5060
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.23.0
> Environment: Mesos 0.23.0 on CentOS 6, also Mesos 0.28.0 on OSX
>Reporter: Tom Petr
>Assignee: zhou xing
>Priority: Minor
> Fix For: 0.29.0
>
>
> I accidentally hit a slave's /files/read.json endpoint with a negative length 
> (ex. http://hostname:5051/files/read.json?path=XXX=0=-100). The 
> HTTP request timed out after 30 seconds with nothing relevant in the slave 
> logs, and subsequent calls to any of the /files endpoints on that slave 
> immediately returned a HTTP 404 response. We ultimately got things working 
> again by restarting the mesos-slave process (checkpointing FTW!), but it'd be 
> wise to guard against negative lengths on the slave's end too.



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

[jira] [Commented] (MESOS-5060) Requesting /files/read.json with a negative length value causes subsequent /files requests to 404.

2016-04-19 Thread zhou xing (JIRA) 

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

zhou xing commented on MESOS-5060:
--

[~greggomann] and [~bmahler], I submitted a draft review request based on my 
previous comments, if you have any comments, please let me know, thanks.

> Requesting /files/read.json with a negative length value causes subsequent 
> /files requests to 404.
> --
>
> Key: MESOS-5060
> URL: https://issues.apache.org/jira/browse/MESOS-5060
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.23.0
> Environment: Mesos 0.23.0 on CentOS 6, also Mesos 0.28.0 on OSX
>Reporter: Tom Petr
>Assignee: zhou xing
>Priority: Minor
> Fix For: 0.29.0
>
>
> I accidentally hit a slave's /files/read.json endpoint with a negative length 
> (ex. http://hostname:5051/files/read.json?path=XXX=0=-100). The 
> HTTP request timed out after 30 seconds with nothing relevant in the slave 
> logs, and subsequent calls to any of the /files endpoints on that slave 
> immediately returned a HTTP 404 response. We ultimately got things working 
> again by restarting the mesos-slave process (checkpointing FTW!), but it'd be 
> wise to guard against negative lengths on the slave's end too.



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

[jira] [Commented] (MESOS-5233) python packages installation is broken

2016-04-19 Thread haosdent (JIRA) 

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

haosdent commented on MESOS-5233:
-

Hi, [~vinodkone] Do you have cycles to shepherd on this?

> python packages installation is broken
> --
>
> Key: MESOS-5233
> URL: https://issues.apache.org/jira/browse/MESOS-5233
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>  Labels: python
>
> After MESOS-4090, all native code is move out of {{src/python/native}}. So 
> the  suffix of mesos.native python packages without specific platform string. 
> This is dismatch with our {{src/Makefile.am}} And it lead to install python 
> packages failed in {{make install}}.



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

[jira] [Assigned] (MESOS-5233) python packages installation is broken

2016-04-19 Thread haosdent (JIRA) 

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

haosdent reassigned MESOS-5233:
---

Assignee: haosdent

> python packages installation is broken
> --
>
> Key: MESOS-5233
> URL: https://issues.apache.org/jira/browse/MESOS-5233
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
>  Labels: python
>
> After MESOS-4090, all native code is move out of {{src/python/native}}. So 
> the  suffix of mesos.native python packages without specific platform string. 
> This is dismatch with our {{src/Makefile.am}} And it lead to install python 
> packages failed in {{make install}}.



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

[jira] [Created] (MESOS-5233) python packages installation is broken

2016-04-19 Thread haosdent (JIRA) 
haosdent created MESOS-5233:
---

 Summary: python packages installation is broken
 Key: MESOS-5233
 URL: https://issues.apache.org/jira/browse/MESOS-5233
 Project: Mesos
  Issue Type: Bug
Reporter: haosdent


After MESOS-4090, all native code is move out of {{src/python/native}}. So the  
suffix of mesos.native python packages without specific platform string. This 
is dismatch with our {{src/Makefile.am}} And it lead to install python packages 
failed in {{make install}}.



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

[jira] [Created] (MESOS-5232) Add capability information to ContainerInfo protobuf message.

2016-04-19 Thread Jojy Varghese (JIRA) 
Jojy Varghese created MESOS-5232:


 Summary: Add capability information to ContainerInfo protobuf 
message.
 Key: MESOS-5232
 URL: https://issues.apache.org/jira/browse/MESOS-5232
 Project: Mesos
  Issue Type: Task
  Components: containerization
Reporter: Jojy Varghese
Assignee: Jojy Varghese


To enable support for capability as first class framework entity, we need to 
add capabilities related information to the ContainerInfo protobuf.



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