[jira] [Created] (MESOS-6122) Mesos slave throws systemd errors even when passed a flag to disable systemd

2016-09-03 Thread Gennady Feldman (JIRA) 
Gennady Feldman created MESOS-6122:
--

 Summary: Mesos slave throws systemd errors even when passed a flag 
to disable systemd
 Key: MESOS-6122
 URL: https://issues.apache.org/jira/browse/MESOS-6122
 Project: Mesos
  Issue Type: Bug
  Components: slave
Affects Versions: 1.0.1
Reporter: Gennady Feldman


Seems like the code in slave/main.cpp is logically in the wrong order:
#ifdef __linux__
  // Initialize systemd if it exists.
if (systemd::exists() && flags.systemd_enable_support) {

Lines 339-341: 
https://github.com/apache/mesos/blob/master/src/slave/main.cpp#L341

The flags should come first before the systemd::exists() check runs.Currently 
the systemd.exists() always runs and there's no way to disable that check from 
running in mesos-slave.



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

[jira] [Updated] (MESOS-6023) Create a binary for the port-mapper plugin

2016-09-03 Thread Jie Yu (JIRA) 

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

Jie Yu updated MESOS-6023:
--
Story Points: 8  (was: 3)

> Create a binary for the port-mapper plugin
> --
>
> Key: MESOS-6023
> URL: https://issues.apache.org/jira/browse/MESOS-6023
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>
> The CNI port mapper plugin needs to be a separate binary that will be invoked 
> by the `network/cni` isolator as a CNI plugin.



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

[jira] [Commented] (MESOS-6023) Create a binary for the port-mapper plugin

2016-09-03 Thread Jie Yu (JIRA) 

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

Jie Yu commented on MESOS-6023:
---

commit 07087efa3ba32d8e146f11c9a604771c6d3bdb64
Author: Avinash sridharan 
Date:   Sat Sep 3 11:06:39 2016 -0700

Added a `PortMapper` class.

This class will embody the logic for implementing the CNI port-mapper
plugin. This patch also added helper functions in `cni::spec` to be able
to log CNI plugin error as a JSON formatted string of `spec::error`.

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

> Create a binary for the port-mapper plugin
> --
>
> Key: MESOS-6023
> URL: https://issues.apache.org/jira/browse/MESOS-6023
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>
> The CNI port mapper plugin needs to be a separate binary that will be invoked 
> by the `network/cni` isolator as a CNI plugin.



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

[jira] [Commented] (MESOS-6096) Update mesos-execute to support launching task groups

2016-09-03 Thread Abhishek Dasgupta (JIRA) 

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

Abhishek Dasgupta commented on MESOS-6096:
--

Took liberty to introduce new `--commands` option in mesos-execute. Expectiong 
suggestions if this is not intended.
Draft patches are here and they will run properly after TaskGroup support is 
completely implemented in master, agent and executor :

https://reviews.apache.org/r/51622/
https://reviews.apache.org/r/51623/

> Update mesos-execute to support launching task groups
> -
>
> Key: MESOS-6096
> URL: https://issues.apache.org/jira/browse/MESOS-6096
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>
> This would be useful to do end to end tests of the TaskGroup support.
> Ideally this should be done after the TaskGroup support is completely 
> implemented in master, agent and executor.



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

[jira] [Commented] (MESOS-5384) Improve error message for missing resources file

2016-09-03 Thread Kris Paprocki (JIRA) 

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

Kris Paprocki commented on MESOS-5384:
--

Actually, documentation/code says:

"To use JSON, pass a JSON-formatted string or use --resources=filepath to 
specify the resources via a file containing a JSON-formatted string. 'filepath' 
can be of the form file:///path/to/file or /path/to/file."

Is the /path/to/file generally allowed/deprecated/not-supported?

Additionally, in the code we give "deprecated" warning when the path is 
specified without 'file://', however only when parsing JSON::Array and 
JSON::Object (see 3rdparty/stout/include/stout/flags/parse.hpp). 
Wouldn't it make sense to make this as a generic rule when reading from 
/path/to/file? 

Also, if we set a generic rule, I propose to move reading the content of the 
/path/to/file from 3rdparty/stout/include/stout/flags/parse.hpp to 
3rdparty/stout/include/stout/flags/fetch.hpp. It was a little bit surprising to 
find another reading hidden in parse.hpp file.

> Improve error message for missing resources file
> 
>
> Key: MESOS-5384
> URL: https://issues.apache.org/jira/browse/MESOS-5384
> Project: Mesos
>  Issue Type: Bug
>  Components: general
>Affects Versions: 0.28.1
> Environment: Centos 7
>Reporter: John Yost
>Assignee: Kris Paprocki
>Priority: Minor
>  Labels: easyfix, newbie
>
> Attempting to specify resources file via 
> --resources=/etc/mesos-slave/small-slave-config.json threw the following 
> error:
> Failed to determine slave resources: Bad value for resources, missing or 
> extra ':' in /etc/mesos-slave/small-slave-config.json
> I confirmed I had valid JSON: 
> [
>   {
> "name": "cpus",
> "type": "SCALAR",
> "scalar": {
>   "value": 0.5
> }
>   },
>   {
> "name": "mem",
> "type": "SCALAR",
> "scalar": {
>   "value": 512
> }
>   }
> ]
> In actuality, I misread to docs with my file pattern. Once I changed to 
> resources=file:///etc/mesos-slave/small-slave-config.json the mesos slave 
> started up fine. Just need a missing file check and corresponding error 
> message to fix this.



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

[jira] [Updated] (MESOS-5275) Add capabilities support for unified containerizer.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5275:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 37, 
Mesosphere Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere 
Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 34, Mesosphere Sprint 
35, Mesosphere Sprint 37, Mesosphere Sprint 38, Mesosphere Sprint 39, 
Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add capabilities support for unified containerizer.
> ---
>
> Key: MESOS-5275
> URL: https://issues.apache.org/jira/browse/MESOS-5275
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> Add capabilities support for unified containerizer. 
> Requirements:
> 1. Use the mesos capabilities API.
> 2. Frameworks be able to add capability requests for containers.
> 3. Agents be able to add maximum allowed capabilities for all containers 
> launched.
> Design document: 
> https://docs.google.com/document/d/1YiTift8TQla2vq3upQr7K-riQ_pQ-FKOCOsysQJROGc/edit#heading=h.rgfwelqrskmd



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

[jira] [Updated] (MESOS-4690) Reorganize 3rdparty directory

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-4690:
-
Sprint: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 36, Mesosphere Sprint 37, Mesosphere Sprint 38, Mesosphere 
Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 33, Mesosphere Sprint 34, Mesosphere Sprint 35, 
Mesosphere Sprint 36, Mesosphere Sprint 37, Mesosphere Sprint 38, Mesosphere 
Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41)

> Reorganize 3rdparty directory
> -
>
> Key: MESOS-4690
> URL: https://issues.apache.org/jira/browse/MESOS-4690
> Project: Mesos
>  Issue Type: Epic
>  Components: build, libprocess, stout
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> This issues is currently being discussed in the dev mailing list:
> http://www.mail-archive.com/dev@mesos.apache.org/msg34349.html



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

[jira] [Updated] (MESOS-5792) Add mesos tests to CMake (make check)

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5792:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add mesos tests to CMake (make check)
> -
>
> Key: MESOS-5792
> URL: https://issues.apache.org/jira/browse/MESOS-5792
> Project: Mesos
>  Issue Type: Improvement
>  Components: build
>Reporter: Srinivas
>Assignee: Srinivas
>  Labels: build, mesosphere
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Provide CMakeLists.txt and configuration files to build mesos tests using 
> CMake.



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

[jira] [Updated] (MESOS-6076) Implement RunTaskGroup handler on the agent.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6076:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Implement RunTaskGroup handler on the agent.
> 
>
> Key: MESOS-6076
> URL: https://issues.apache.org/jira/browse/MESOS-6076
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: mesosphere
>
> We need to implement the {{RunTaskGroup}} handler on the agent. This would be 
> similar to the {{RunTask}} handler that already exists except that this would 
> have the relevant logic to send the task group to the executor atomically.
> Ideally, we would like to re-use as much pieces of the already existing 
> functionality from the {{runTask()}} handler. We also need to add a state 
> {{queuedTaskGroups}} since it is needed for dispatching queued task groups to 
> the executor upon registration. Also, we should ensure to populate 
> {{queuedTasks}} with the task group information too thereby enabling users to 
> query it via the `/state` endpoint/master reconciliation messages etc.



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

[jira] [Updated] (MESOS-5931) Support auto backend in Unified Containerizer.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5931:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Support auto backend in Unified Containerizer.
> --
>
> Key: MESOS-5931
> URL: https://issues.apache.org/jira/browse/MESOS-5931
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Gilbert Song
>  Labels: backend, containerizer, mesosphere
>
> Currently in Unified Containerizer, copy backend will be selected by default. 
> This is not ideal, especially for production environment. It would take a 
> long time to prepare an huge container image to copy it from the store to 
> provisioner.
> Ideally, we should support `auto backend`, which would 
> automatically/intelligently select the best/optimal backend for image 
> provisioner if user does not specify one from the agent flag.
> We should have a logic design first in this ticket, to determine how we want 
> to choose the right backend (e.g., overlayfs or aufs should be preferred if 
> available from the kernel).



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

[jira] [Updated] (MESOS-5303) Add capabilities support for mesos execute cli.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5303:
-
Sprint: Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 37, 
Mesosphere Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere 
Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 34, Mesosphere Sprint 
35, Mesosphere Sprint 37, Mesosphere Sprint 38, Mesosphere Sprint 39, 
Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add capabilities support for mesos execute cli.
> ---
>
> Key: MESOS-5303
> URL: https://issues.apache.org/jira/browse/MESOS-5303
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Jojy Varghese
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> Add support for `user` and `capabilities` to execute cli. This will help in 
> testing the `capabilities` feature for unified containerizer.



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

[jira] [Updated] (MESOS-3910) Libprocess: Implement cleanup of the SocketManager in process::finalize

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-3910:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Libprocess: Implement cleanup of the SocketManager in process::finalize
> ---
>
> Key: MESOS-3910
> URL: https://issues.apache.org/jira/browse/MESOS-3910
> Project: Mesos
>  Issue Type: Task
>  Components: libprocess, test
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere
>
> The {{socket_manager}} and {{process_manager}} are intricately tied together. 
>  Currently, only the {{process_manager}} is cleaned up by 
> {{process::finalize}}.
> To clean up the {{socket_manager}}, we must close all sockets and deallocate 
> any existing {{HttpProxy}} or {{Encoder}} objects.  And we should prevent 
> further objects from being created/tracked by the {{socket_manager}}.
> *Proposal*
> # Clean up all processes other than {{gc}}.  This will clear all links and 
> delete all {{HttpProxy}} s while {{socket_manager}} still exists.
> # Close all sockets via {{SocketManager::close}}.  All of {{socket_manager}} 
> 's state is cleaned up via {{SocketManager::close}}, including termination of 
> {{HttpProxy}} (termination is idempotent, meaning that killing {{HttpProxy}} 
> s via {{process_manager}} is safe).
> # At this point, {{socket_manager}} should be empty and only the {{gc}} 
> process should be running.  (Since we're finalizing, assume there are no 
> threads trying to spawn processes.)  {{socket_manager}} can be deleted.
> # {{gc}} can be deleted.  This is currently a leaked pointer, so we'll also 
> need to track and delete that.
> # {{process_manager}} should be devoid of processes, so we can proceed with 
> cleanup (join threads, stop the {{EventLoop}}, etc).



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

[jira] [Updated] (MESOS-5779) Allow Docker v1 ImageManifests to be parsed from the output of `docker inspect`

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5779:
-
Sprint: Mesosphere Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 41, 
Mesosphere Sprint 42  (was: Mesosphere Sprint 38, Mesosphere Sprint 39, 
Mesosphere Sprint 41)

> Allow Docker v1 ImageManifests to be parsed from the output of `docker 
> inspect`
> ---
>
> Key: MESOS-5779
> URL: https://issues.apache.org/jira/browse/MESOS-5779
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Kevin Klues
>
> The `docker::spec::v1::ImageManifest` protobuf implements the
> official v1 image manifest specification found at:
> 
> https://github.com/docker/docker/blob/master/image/spec/v1.md
> 
> The field names in this spec are all written in snake_case as are the
> field names of the JSON representing the image manifest when reading
> it from disk (for example after performing a `docker save`). As such,
> the protobuf for ImageManifest also provides these fields in
> snake_case. Unfortunately, the `docker inspect` command also provides
> a method of retrieving the JSON for an image manifest, with one major
> caveat -- it represents all of its top level keys in CamelCase.
> 
> To allow both representations to be parsed in the same way, we
> should intercept the incoming JSON from either source (disk or `docker
> inspect`) and convert it to a canonical snake_case representation.



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

[jira] [Updated] (MESOS-6104) Potential FD double close in libevent's implementation of `sendfile`.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6104:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Potential FD double close in libevent's implementation of `sendfile`.
> -
>
> Key: MESOS-6104
> URL: https://issues.apache.org/jira/browse/MESOS-6104
> Project: Mesos
>  Issue Type: Bug
>  Components: webui
>Affects Versions: 0.27.3, 0.28.2, 1.0.1
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>Priority: Critical
>  Labels: mesosphere, ssl
>
> Repro copied from: https://reviews.apache.org/r/51509/
> It is possible to make the master CHECK fail by repeatedly hitting the web UI 
> and reloading the static assets:
> 1) Paste lots of text (16KB or more) of text into 
> `src/webui/master/static/home.html`.  The more text, the more reliable the 
> repro.
> 2) Start the master with SSL enabled:
> {code}
> LIBPROCESS_SSL_ENABLED=true LIBPROCESS_SSL_KEY_FILE=key.pem 
> LIBPROCESS_SSL_CERT_FILE=cert.pem bin/mesos-master.sh --work_dir=/tmp/master
> {code}
> 3) Run two instances of this python script repeatedly:
> {code}
> import socket
> import ssl
> s = ssl.wrap_socket(socket.socket())
> s.connect(("localhost", 5050))
> s.sendall("""GET /static/home.html HTTP/1.1
> User-Agent: foobar
> Host: localhost:5050
> Accept: */*
> Connection: Keep-Alive
> """)
> # The HTTP part of the response
> print s.recv(1000)
> {code}
> i.e. 
> {code}
> while python test.py; do :; done & while python test.py; do :; done
> {code}



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

[jira] [Updated] (MESOS-6052) Unable to launch containers on CNI networks on CoreOS

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6052:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Unable to launch containers on CNI networks on CoreOS
> -
>
> Key: MESOS-6052
> URL: https://issues.apache.org/jira/browse/MESOS-6052
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Affects Versions: 1.0.0
> Environment: Linux
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
> Fix For: 1.1.0
>
>
> CoreOS does not have an `/etc/hosts`. Currently, in the `network/cni` 
> isolator, if we don't see a `/etc/hosts` on the host filesystem we don't bind 
> mount the containers `hosts` file to this target for the `command executor`. 
> On distros such as CoreOS this fails the container launch since the 
> `libprocess` initialization of the `command executor` fails cause it can't 
> resolve its `hostname`.
> We should be creating the `/etc/hosts` and `/etc/hostname` files when they 
> are absent on the host filesystem since creating these files should not 
> affect name resolution on the host network namespace, and it will allow the 
> `/etc/hosts` file to be bind mounted correctly and allow name resolution in 
> the containers network namespace as well. 



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

[jira] [Updated] (MESOS-3934) Libprocess: Unify the initialization of the MetricsProcess and ReaperProcess

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-3934:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Libprocess: Unify the initialization of the MetricsProcess and ReaperProcess
> 
>
> Key: MESOS-3934
> URL: https://issues.apache.org/jira/browse/MESOS-3934
> Project: Mesos
>  Issue Type: Task
>  Components: libprocess, test
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere
>
> Related to this 
> [TODO|https://github.com/apache/mesos/blob/aa0cd7ed4edf1184cbc592b5caa2429a8373e813/3rdparty/libprocess/src/process.cpp#L949-L950].
> The {{MetricsProcess}} and {{ReaperProcess}} are global processes 
> (singletons) which are initialized upon first use.  The two processes could 
> be initialized alongside the {{gc}}, {{help}}, {{logging}}, {{profiler}}, and 
> {{system}} (statistics) processes inside {{process::initialize}}.
> This is also necessary for libprocess re-initialization.



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

[jira] [Updated] (MESOS-5570) Improve CHANGELOG and upgrades.md

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5570:
-
Sprint: Mesosphere Sprint 37, Mesosphere Sprint 38, Mesosphere Sprint 39, 
Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 37, 
Mesosphere Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 41)

> Improve CHANGELOG and upgrades.md
> -
>
> Key: MESOS-5570
> URL: https://issues.apache.org/jira/browse/MESOS-5570
> Project: Mesos
>  Issue Type: Documentation
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> Currently we have a lot of data duplication between the CHANGELOG and 
> upgrades.md. We should try to improve this and potentially make the CHANGLOG 
> a markdown file as well. For inspiration see the Hadoop changelog: 
> https://github.com/apache/hadoop/blob/2e1d0ff4e901b8313c8d71869735b94ed8bc40a0/hadoop-common-project/hadoop-common/src/site/markdown/release/1.2.0/CHANGES.1.2.0.md



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

[jira] [Updated] (MESOS-3753) Test the HTTP Scheduler library with SSL enabled

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-3753:
-
Sprint: Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41, 
Mesosphere Sprint 42  (was: Mesosphere Sprint 39, Mesosphere Sprint 40, 
Mesosphere Sprint 41)

> Test the HTTP Scheduler library with SSL enabled
> 
>
> Key: MESOS-3753
> URL: https://issues.apache.org/jira/browse/MESOS-3753
> Project: Mesos
>  Issue Type: Story
>  Components: framework, HTTP API, test
>Reporter: Joseph Wu
>Assignee: Greg Mann
>  Labels: mesosphere, security
>
> Currently, the HTTP Scheduler library does not support SSL-enabled Mesos.  
> (You can manually test this by spinning up an SSL-enabled master and attempt 
> to run the event-call framework example against it.)
> We need to add tests that check the HTTP Scheduler library against 
> SSL-enabled Mesos:
> * with downgrade support,
> * with required framework/client-side certifications,
> * with/without verification of certificates (master-side),
> * with/without verification of certificates (framework-side),
> * with a custom certificate authority (CA)
> These options should be controlled by the same environment variables found on 
> the [SSL user doc|http://mesos.apache.org/documentation/latest/ssl/].
> Note: This issue will be broken down into smaller sub-issues as bugs/problems 
> are discovered.



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

[jira] [Updated] (MESOS-4766) Improve allocator performance.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-4766:
-
Sprint: Mesosphere Sprint 32, Mesosphere Sprint 33, Mesosphere Sprint 34, 
Mesosphere Sprint 35, Mesosphere Sprint 36, Mesosphere Sprint 37, Mesosphere 
Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41, 
Mesosphere Sprint 42  (was: Mesosphere Sprint 32, Mesosphere Sprint 33, 
Mesosphere Sprint 34, Mesosphere Sprint 35, Mesosphere Sprint 36, Mesosphere 
Sprint 37, Mesosphere Sprint 38, Mesosphere Sprint 39, Mesosphere Sprint 40, 
Mesosphere Sprint 41)

> Improve allocator performance.
> --
>
> Key: MESOS-4766
> URL: https://issues.apache.org/jira/browse/MESOS-4766
> Project: Mesos
>  Issue Type: Epic
>  Components: allocation
>Reporter: Benjamin Mahler
>Assignee: Michael Park
>Priority: Critical
>
> This is an epic to track the various tickets around improving the performance 
> of the allocator, including the following:
> * Preventing un-necessary backup of the allocator.
> * Reducing the cost of allocations and allocator state updates.
> * Improving performance of the DRF sorter.
> * More benchmarking to simulate scenarios with performance issues.



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

[jira] [Updated] (MESOS-6088) Update 'launcher' to checkpoint exit status of launched process.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6088:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Update 'launcher' to checkpoint exit status of launched process.
> 
>
> Key: MESOS-6088
> URL: https://issues.apache.org/jira/browse/MESOS-6088
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Fix For: 1.1.0
>
>
> Currently the 'mesos-containerizer launch' binary simply execs
> into the actual command we wanted to launch after doing some set of
> preperatory work. The problem with this approach, however, is that
> this gives us no opportunity to checkpoint the exit status of the
> command so the agent can recover it in cases where it is offline at
> the time the command completes.  We should add support for this 
> checkpointing.



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

[jira] [Updated] (MESOS-4778) Add appc/runtime isolator for runtime isolation for appc images.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-4778:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add appc/runtime isolator for runtime isolation for appc images.
> 
>
> Key: MESOS-4778
> URL: https://issues.apache.org/jira/browse/MESOS-4778
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Jie Yu
>Assignee: Srinivas
>  Labels: containerizer, isolator, mesosphere
>
> Appc image also contains runtime information like 'exec', 'env', 
> 'workingDirectory' etc.
> https://github.com/appc/spec/blob/master/spec/aci.md
> Similar to docker images, we need to support a subset of them (mainly 'exec', 
> 'env' and 'workingDirectory').



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

[jira] [Updated] (MESOS-5966) Add libprocess HTTP tests with SSL support

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5966:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add libprocess HTTP tests with SSL support
> --
>
> Key: MESOS-5966
> URL: https://issues.apache.org/jira/browse/MESOS-5966
> Project: Mesos
>  Issue Type: Task
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: mesosphere
>
> Libprocess contains SSL unit tests which test our SSL support using simple 
> sockets. We should add tests which also make use of libprocess's various HTTP 
> classes and helpers in a variety of SSL configurations.



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

[jira] [Updated] (MESOS-6053) Combine test helpers into one single binary.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6053:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Combine test helpers into one single binary.
> 
>
> Key: MESOS-6053
> URL: https://issues.apache.org/jira/browse/MESOS-6053
> Project: Mesos
>  Issue Type: Improvement
>  Components: technical debt, test
>Reporter: Jie Yu
>Assignee: Jie Yu
>  Labels: mesosphere
>
> Currently, we have multiple test helper binaries
> setns-test-helper
> memory-test-helper
> active-user-test-helper
> And we are adding more:
> capabilities-test-helper (https://reviews.apache.org/r/50269)
> Since most of them already use `Subcommand`, we should combine them into one 
> single binary. That will simply adding a new test helper that has to run in a 
> separate process.



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

[jira] [Updated] (MESOS-5967) Add support for 'docker image inspect' in our docker abstraction

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5967:
-
Sprint: Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere Sprint 42  
(was: Mesosphere Sprint 40, Mesosphere Sprint 41)

> Add support for 'docker image inspect' in our docker abstraction
> 
>
> Key: MESOS-5967
> URL: https://issues.apache.org/jira/browse/MESOS-5967
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>  Labels: gpu, mesosphere
> Fix For: 1.1.0
>
>
> Our current {{docker inspect}} support in our docker abstraction only 
> supports inspecting containers (not images).  We should expand this support 
> to images.



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

[jira] [Updated] (MESOS-5582) Create a `cgroups/devices` isolator.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-5582:
-
Sprint: Mesosphere Sprint 36, Mesosphere Sprint 37, Mesosphere Sprint 38, 
Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41, Mesosphere 
Sprint 42  (was: Mesosphere Sprint 36, Mesosphere Sprint 37, Mesosphere Sprint 
38, Mesosphere Sprint 39, Mesosphere Sprint 40, Mesosphere Sprint 41)

> Create a `cgroups/devices` isolator.
> 
>
> Key: MESOS-5582
> URL: https://issues.apache.org/jira/browse/MESOS-5582
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>  Labels: gpu, isolator, mesosphere
>
> Currently, all the logic for the `cgroups/devices` isolator is bundled into 
> the Nvidia GPU Isolator. We should abstract it out into it's own component 
> and remove the redundant logic from the Nvidia GPU Isolator. Assuming the 
> guaranteed ordering between isolators from MESOS-5581, we can be sure that 
> the dependency order between the `cgroups/devices` and `gpu/nvidia` isolators 
> is met.



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

[jira] [Updated] (MESOS-6067) Support provisioner to be nested aware for Mesos Pods.

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6067:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Support provisioner to be nested aware for Mesos Pods.
> --
>
> Key: MESOS-6067
> URL: https://issues.apache.org/jira/browse/MESOS-6067
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Gilbert Song
>  Labels: containerizer, provisioner
>
> The provisioner has to be nested aware for sub-container provisioning, as 
> well as recovery and nested container destroy. Better to support multi-level 
> hierarchy. 



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

[jira] [Updated] (MESOS-6040) Add a CMake build for `mesos-port-mapper`

2016-09-03 Thread Artem Harutyunyan (JIRA) 

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

Artem Harutyunyan updated MESOS-6040:
-
Sprint: Mesosphere Sprint 41, Mesosphere Sprint 42  (was: Mesosphere Sprint 
41)

> Add a CMake build for `mesos-port-mapper`
> -
>
> Key: MESOS-6040
> URL: https://issues.apache.org/jira/browse/MESOS-6040
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Avinash Sridharan
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> Once the port-mapper binary compiles with GNU make, we need to modify the 
> CMake to build the port-mapper binary as well. 



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

[jira] [Commented] (MESOS-6121) Unable to make on 1.0.1 version

2016-09-03 Thread haosdent (JIRA) 

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

haosdent commented on MESOS-6121:
-

I saw your system is 32 bit which Mesos don't support.

> Unable to make on 1.0.1 version 
> 
>
> Key: MESOS-6121
> URL: https://issues.apache.org/jira/browse/MESOS-6121
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: Ubuntu 14.04
>Reporter: Ankur Verma
>
> Unable to make on 1.0.1 version , getting errors
> vagrant@precise32:~/mesos/build$ make -j 1
> Making all in .
> make[1]: Entering directory `/home/vagrant/mesos/build'
> make[1]: Nothing to be done for `all-am'.
> make[1]: Leaving directory `/home/vagrant/mesos/build'
> Making all in 3rdparty
> make[1]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make  all-recursive
> make[2]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> Making all in .
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make[3]: Nothing to be done for `all-am'.
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in stout
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in include
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in libprocess
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in include
> make[5]: Entering directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[2]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> make[1]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in src
> make[1]: Entering directory `/home/vagrant/mesos/build/src'
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.Log
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.MesosExecutorDriver
> Error: Class com.google.protobuf.GeneratedMessage could not be found.
> make[1]: *** [java/jni/org_apache_mesos_MesosExecutorDriver.h] Error 1
> make[1]: Leaving directory `/home/vagrant/mesos/build/src'
> make: *** [all-recursive] Error 1
> vagrant@precise32:~/mesos/build$ cd ..
> vagrant@precise32:~/mesos$ ls



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

[jira] [Commented] (MESOS-6121) Unable to make on 1.0.1 version

2016-09-03 Thread Ankur Verma (JIRA) 

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

Ankur Verma commented on MESOS-6121:


I was following mesos getting started page

http://mesos.apache.org/gettingstarted/

# Change working directory.
$ cd mesos

# Bootstrap (Only required if building from git repository).
$ ./bootstrap

# Configure and build.
$ mkdir build
$ cd build
$ ../configure
$ make

> Unable to make on 1.0.1 version 
> 
>
> Key: MESOS-6121
> URL: https://issues.apache.org/jira/browse/MESOS-6121
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: Ubuntu 14.04
>Reporter: Ankur Verma
>
> Unable to make on 1.0.1 version , getting errors
> vagrant@precise32:~/mesos/build$ make -j 1
> Making all in .
> make[1]: Entering directory `/home/vagrant/mesos/build'
> make[1]: Nothing to be done for `all-am'.
> make[1]: Leaving directory `/home/vagrant/mesos/build'
> Making all in 3rdparty
> make[1]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make  all-recursive
> make[2]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> Making all in .
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make[3]: Nothing to be done for `all-am'.
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in stout
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in include
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in libprocess
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in include
> make[5]: Entering directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[2]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> make[1]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in src
> make[1]: Entering directory `/home/vagrant/mesos/build/src'
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.Log
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.MesosExecutorDriver
> Error: Class com.google.protobuf.GeneratedMessage could not be found.
> make[1]: *** [java/jni/org_apache_mesos_MesosExecutorDriver.h] Error 1
> make[1]: Leaving directory `/home/vagrant/mesos/build/src'
> make: *** [all-recursive] Error 1
> vagrant@precise32:~/mesos/build$ cd ..
> vagrant@precise32:~/mesos$ ls



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

[jira] [Commented] (MESOS-6121) Unable to make on 1.0.1 version

2016-09-03 Thread Ankur Verma (JIRA) 

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

Ankur Verma commented on MESOS-6121:


I have updated my vagrant box from ubuntu 12 to ubuntu 14
When i login to the machine... It displays like this

Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.2.0-23-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/
New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Welcome to your Vagrant-built virtual machine.
Last login: Fri Sep  2 08:18:22 2016 from 10.0.2.2
vagrant@precise32:~$
vagrant@precise32:~$

vagrant@precise32:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/;
SUPPORT_URL="http://help.ubuntu.com/;
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;





> Unable to make on 1.0.1 version 
> 
>
> Key: MESOS-6121
> URL: https://issues.apache.org/jira/browse/MESOS-6121
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: Ubuntu 14.04
>Reporter: Ankur Verma
>
> Unable to make on 1.0.1 version , getting errors
> vagrant@precise32:~/mesos/build$ make -j 1
> Making all in .
> make[1]: Entering directory `/home/vagrant/mesos/build'
> make[1]: Nothing to be done for `all-am'.
> make[1]: Leaving directory `/home/vagrant/mesos/build'
> Making all in 3rdparty
> make[1]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make  all-recursive
> make[2]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> Making all in .
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty'
> make[3]: Nothing to be done for `all-am'.
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in stout
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in include
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/stout'
> Making all in libprocess
> make[3]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make  all-recursive
> make[4]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in .
> make[5]: Entering directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> Making all in include
> make[5]: Entering directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory 
> `/home/vagrant/mesos/build/3rdparty/libprocess/include'
> make[4]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[3]: Leaving directory `/home/vagrant/mesos/build/3rdparty/libprocess'
> make[2]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> make[1]: Leaving directory `/home/vagrant/mesos/build/3rdparty'
> Making all in src
> make[1]: Entering directory `/home/vagrant/mesos/build/src'
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.Log
> /usr/lib/jvm/java-7-openjdk-i386/bin/javah -d java/jni
>   \
> -classpath 
> java/target/mesos-1.1.0.jar:/home/vagrant/mesos/build/src/java/target/protobuf-java-2.6.1.jar
> \
>   org.apache.mesos.MesosExecutorDriver
> Error: Class com.google.protobuf.GeneratedMessage could not be found.
> make[1]: *** [java/jni/org_apache_mesos_MesosExecutorDriver.h] Error 1
> make[1]: Leaving directory `/home/vagrant/mesos/build/src'
> make: *** [all-recursive] Error 1
> vagrant@precise32:~/mesos/build$ cd ..
> vagrant@precise32:~/mesos$ ls



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