Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

2016-03-07 Thread Shuai Lin 
Maybe also https://issues.apache.org/jira/browse/MESOS-4877 and
https://issues.apache.org/jira/browse/MESOS-4878 ?

On Tue, Mar 8, 2016 at 9:13 AM, Jie Yu  wrote:

> I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as well
> if you guys plan to cut another RC
>
> On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
> daniel.osbo...@metaswitch.com> wrote:
>
>> -1
>>
>> If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively
>> small patch which restores Mesos' ability to extract Docker assigned IPs.
>> This has been broken with Docker 1.10's release over  a month ago, and
>> prevents service discovery and DNS from working.
>>
>> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
>> RB# 43093: https://reviews.apache.org/r/43093/
>>
>> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as
>> expected.
>>
>> Apologies for not bringing this to attention earlier.
>>
>> Thanks all,
>> Dan
>>
>> -Original Message-
>> From: Vinod Kone [mailto:vinodk...@apache.org]
>> Sent: Thursday, March 3, 2016 5:44 PM
>> To: dev ; user 
>> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>>
>> Hi all,
>>
>>
>> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>>
>>
>> 0.28.0 includes the following:
>>
>>
>> 
>>
>>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
>> subsystem in
>>
>> Linux. The cgroups/net_cls isolator allows operators to provide
>> network
>>
>>
>> performance isolation and network segmentation for containers within
>> a Mesos
>>
>> cluster. To enable the cgroups/net_cls isolator, append
>> `cgroups/net_cls` to
>>
>> the `--isolation` flag when starting the slave. Please refer to
>>
>>
>> docs/mesos-containerizer.md for more details.
>>
>>
>>
>>
>>
>>   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
>> "2.5
>>
>>
>> CPUs") has changed. Mesos now reliably supports resources with up to
>> three
>>
>> decimal digits of precision (e.g., "2.501 CPUs"); resources with more
>> than
>>
>> three decimal digits of precision will be rounded. Internally,
>> resource math
>>
>> is now done using a fixed-point format that supports three decimal
>> digits of
>>
>> precision, and then converted to/from floating point for input and
>> output,
>>
>> respectively. Frameworks that do their own resource math and
>> manipulate
>>
>>
>> fractional resources may observe differences in roundoff error and
>> numerical
>>
>> precision.
>>
>>
>>
>>
>>
>>   * [MESOS-4479] - Reserved resources can now optionally include "labels".
>>
>>
>> Labels are a set of key-value pairs that can be used to associate
>> metadata
>>
>> with a reserved resource. For example, frameworks can use this
>> feature to
>>
>> distinguish between two reservations for the same role at the same
>> agent
>>
>> that are intended for different purposes.
>>
>>
>>
>>
>>
>>   * [MESOS-2840] - **Experimental** support for container images in Mesos
>>
>>
>> containerizer (a.k.a. Unified Containerizer). This allows frameworks
>> to
>>
>>
>> launch Docker/Appc containers using Mesos containerizer without
>> relying on
>>
>> docker daemon (engine) or rkt. The isolation of the containers is
>> done using
>>
>> isolators. Please refer to docs/container-image.md for currently
>> supported
>>
>> features and limitations.
>>
>>
>>
>>
>>
>>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This
>>
>>
>> allows executors to send HTTP requests to the /api/v1/executor agent
>>
>>
>> endpoint without the need for an executor driver. Please refer to
>>
>>
>> docs/executor-http-api.md for more details.
>>
>>
>>
>>
>>
>> Additional API Changes:
>>
>>
>>   * [MESOS-4066] - Agent should not return partial state when a request
>> is made to /state endpoint during recovery.
>>
>>   * [MESOS-4547] - Introduce TASK_KILLING state.
>>
>>
>>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
>> Scheduler API.
>>
>>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
>> ACLs to `roles`.
>>
>>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
>> Scheduler API.
>>
>>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
>> ACLs to `roles`.
>>
>>   * [MESOS-3583] - Add stream IDs for HTTP schedulers.
>>
>>
>> The CHANGELOG for the release is available at:
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc1
>>
>>
>> 
>>
>>
>> The candidate for Mesos 0.28.0 release is available at:
>>
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz
>>
>>
>> The tag to be voted on is

Re: Re: Mesos 0.25 not incresing Staged/Started counters in the UI

2016-03-07 Thread Benjamin Mahler 
Non-terminal states are gauges (instantaneous measurements) whereas the
terminal states are counters (always increasing, at least for the lifetime
of a master process).

Hopefully this image doesn't get stripped, but we improved the wording here
to clarify which are gauges and which are counters:

[image: Inline image 1]

Notice that present-tense means gauge, past-tense means counter.

On Wed, Feb 24, 2016 at 8:26 AM, haosdent  wrote:

> >My point is there is no straightforward way of telling how many tasks had
> been running on the cluster since it is up. Or am i missing something?
>
> I think we could get it from sum up "master/task_*"  metrics?
>
> On Wed, Feb 24, 2016 at 9:04 PM, Geoffroy Jabouley <
> geoffroy.jabou...@gmail.com> wrote:
>
>> Thanks for the clarification. Does staged means "currently in staging state"?
>>
>> In previous versions of Mesos (at least 0.22.1), the Staged value was 
>> increased for each staged tasks, to you could tell "X tasks have been 
>> executed on the cluster".
>>
>> My point is there is no straightforward way of telling how many tasks had 
>> been running on the cluster since it is up. Or am i missing something?
>>
>>
>>
>>
>>
>> If you have some tasks which state is not equal to TASK_STAGING, it would
>> become non-zero.
>>
>> On Wed, Feb 24, 2016 at 8:23 PM, Geoffroy Jabouley 
>>  wrote:
>>
>> > Hi again
>> >
>> > just checked the /metrics/snapshot endpoint. Staged value is zero. Is this
>> > normal?
>> >
>> > {
>> >"allocator\/event_queue_dispatches":0.0,
>> >"frameworks\/jenkins\/messages_processed":9.0,
>> >"frameworks\/jenkins\/messages_received":9.0,
>> >"master\/cpus_percent":0.0958,
>> >"master\/cpus_revocable_percent":0.0,
>> >"master\/cpus_revocable_total":0.0,
>> >"master\/cpus_revocable_used":0.0,
>> >"master\/cpus_total":24.0,
>> >"master\/cpus_used":2.3,
>> >"master\/disk_percent":0.0,
>> >"master\/disk_revocable_percent":0.0,
>> >"master\/disk_revocable_total":0.0,
>> >"master\/disk_revocable_used":0.0,
>> >"master\/disk_total":138161.0,
>> >"master\/disk_used":0.0,
>> >"master\/dropped_messages":6.0,
>> >"master\/elected":1.0,
>> >"master\/event_queue_dispatches":26.0,
>> >"master\/event_queue_http_requests":0.0,
>> >"master\/event_queue_messages":0.0,
>> >"master\/frameworks_active":2.0,
>> >"master\/frameworks_connected":2.0,
>> >"master\/frameworks_disconnected":0.0,
>> >"master\/frameworks_inactive":0.0,
>> >"master\/invalid_executor_to_framework_messages":0.0,
>> >"master\/invalid_framework_to_executor_messages":0.0,
>> >"master\/invalid_status_update_acknowledgements":0.0,
>> >"master\/invalid_status_updates":256.0,
>> >"master\/mem_percent":0.268649930174402,
>> >"master\/mem_revocable_percent":0.0,
>> >"master\/mem_revocable_total":0.0,
>> >"master\/mem_revocable_used":0.0,
>> >"master\/mem_total":92373.0,
>> >"master\/mem_used":24816.0,
>> >"master\/messages_authenticate":0.0,
>> >"master\/messages_deactivate_framework":0.0,
>> >"master\/messages_decline_offers":45642.0,
>> >"master\/messages_executor_to_framework":0.0,
>> >"master\/messages_exited_executor":0.0,
>> >"master\/messages_framework_to_executor":0.0,
>> >"master\/messages_kill_task":1401.0,
>> >"master\/messages_launch_tasks":1525.0,
>> >"master\/messages_reconcile_tasks":5100.0,
>> >"master\/messages_register_framework":0.0,
>> >"master\/messages_register_slave":3.0,
>> >"master\/messages_reregister_framework":0.0,
>> >"master\/messages_reregister_slave":3.0,
>> >"master\/messages_resource_request":0.0,
>> >"master\/messages_revive_offers":78.0,
>> >"master\/messages_status_update":3252.0,
>> >"master\/messages_status_update_acknowledgement":1964.0,
>> >"master\/messages_suppress_offers":0.0,
>> >"master\/messages_unregister_framework":183.0,
>> >"master\/messages_unregister_slave":0.0,
>> >"master\/messages_update_slave":6.0,
>> >"master\/outstanding_offers":0.0,
>> >"master\/recovery_slave_removals":0.0,
>> >"master\/slave_registrations":3.0,
>> >"master\/slave_removals":0.0,
>> >"master\/slave_removals\/reason_registered":0.0,
>> >"master\/slave_removals\/reason_unhealthy":0.0,
>> >"master\/slave_removals\/reason_unregistered":0.0,
>> >"master\/slave_reregistrations":0.0,
>> >"master\/slave_shutdowns_canceled":0.0,
>> >"master\/slave_shutdowns_completed":0.0,
>> >"master\/slave_shutdowns_scheduled":0.0,
>> >"master\/slaves_active":3.0,
>> >"master\/slaves_connected":3.0,
>> >"master\/slaves_disconnected":0.0,
>> >"master\/slaves_inactive":0.0,
>> >"master\/task_killed\/source_master\/reason_framework_
>> removed":1065.0,
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > *   "master\/tasks_error":0.0,   "master\/tasks_failed":4.0,
>> >

Re: mesos agent not recovering after ZK init failure

2016-03-07 Thread Sharma Podila 
Sure, will do.


On Mon, Mar 7, 2016 at 5:54 PM, Benjamin Mahler  wrote:

> Very surprising.. I don't have any ideas other than trying to replicate
> the scenario in a test.
>
> Please do keep us posted if you encounter it again and gain more
> information.
>
> On Fri, Feb 26, 2016 at 4:34 PM, Sharma Podila 
> wrote:
>
>> MESOS-4795 created.
>>
>> I don't have the exit status. We haven't seen a repeat yet, will catch
>> the exit status next time it happens.
>>
>> Yes, removing the metadata directory was the only way it was resolved.
>> This happened on multiple hosts requiring the same resolution.
>>
>>
>> On Thu, Feb 25, 2016 at 6:37 PM, Benjamin Mahler 
>> wrote:
>>
>>> Feel free to create one. I don't have enough information to know what
>>> the issue is without doing some further investigation, but if the situation
>>> you described is accurate it seems like a there are two strange bugs:
>>>
>>> -the silent exit (do you not have the exit status?), and
>>> -the flapping from ZK errors that needed the meta data directory to be
>>> removed to resolve (are you convinced the removal of the meta directory is
>>> what solved it?)
>>>
>>> It would be good to track these issues in case they crop up again.
>>>
>>> On Tue, Feb 23, 2016 at 2:51 PM, Sharma Podila 
>>> wrote:
>>>
 Hi Ben,

 Let me know if there is a new issue created for this, I would like to
 add myself to watch it.
 Thanks.



 On Wed, Feb 10, 2016 at 9:54 AM, Sharma Podila 
 wrote:

> Hi Ben,
>
> That is accurate, with one additional line:
>
> -Agent running fine with 0.24.1
> -Transient ZK issues, slave flapping with zookeeper_init failure
> -ZK issue resolved
> -Most agents stop flapping and function correctly
> -Some agents continue flapping, but silent exit after printing the
> detector.cpp:481 log line.
> -The agents that continue to flap repaired with manual removal of
> contents in mesos-slave's working dir
>
>
>
> On Wed, Feb 10, 2016 at 9:43 AM, Benjamin Mahler 
> wrote:
>
>> Hey Sharma,
>>
>> I didn't quite follow the timeline of events here or how the agent
>> logs you posted fit into the timeline of events. Here's how I 
>> interpreted:
>>
>> -Agent running fine with 0.24.1
>> -Transient ZK issues, slave flapping with zookeeper_init failure
>> -ZK issue resolved
>> -Most agents stop flapping and function correctly
>> -Some agents continue flapping, but silent exit after printing the
>> detector.cpp:481 log line.
>>
>> Is this accurate? What is the exit code from the silent exit?
>>
>> On Tue, Feb 9, 2016 at 9:09 PM, Sharma Podila 
>> wrote:
>>
>>> Maybe related, but, maybe different since a new process seems to
>>> find the master leader and still aborts, never recovering with restarts
>>> until work dir data is removed.
>>> It is happening in 0.24.1.
>>>
>>>
>>>
>>>
>>> On Tue, Feb 9, 2016 at 11:53 AM, Vinod Kone 
>>> wrote:
>>>
 MESOS-1326 was fixed in 0.19.0 (set the fix version now). But I
 guess you are saying it is somehow related but not exactly the same 
 issue?

 On Tue, Feb 9, 2016 at 11:46 AM, Raúl Gutiérrez Segalés <
 r...@itevenworks.net> wrote:

> On 9 February 2016 at 11:04, Sharma Podila 
> wrote:
>
>> We had a few mesos agents stuck in an unrecoverable state after a
>> transient ZK init error. Is this a known problem? I wasn't able to 
>> find an
>> existing jira item for this. We are on 0.24.1 at this time.
>>
>> Most agents were fine, except a handful. These handful of agents
>> had their mesos-slave process constantly restarting. The .INFO 
>> logfile had
>> the following contents below, before the process exited, with no 
>> error
>> messages. The restarts were happening constantly due to an existing 
>> service
>> keep alive strategy.
>>
>> To fix it, we manually stopped the service, removed the data in
>> the working dir, and then restarted it. The mesos-slave process was 
>> able to
>> restart then. The manual intervention needed to resolve it is 
>> problematic.
>>
>> Here's the contents of the various log files on the agent:
>>
>> The .INFO logfile for one of the restarts before mesos-slave
>> process exited with no other error messages:
>>
>> Log file created at: 2016/02/09 02:12:48
>> Running on machine: titusagent-main-i-7697a9c5
>> Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line]

Re: mesos agent not recovering after ZK init failure

2016-03-07 Thread Benjamin Mahler 
Very surprising.. I don't have any ideas other than trying to replicate the
scenario in a test.

Please do keep us posted if you encounter it again and gain more
information.

On Fri, Feb 26, 2016 at 4:34 PM, Sharma Podila  wrote:

> MESOS-4795 created.
>
> I don't have the exit status. We haven't seen a repeat yet, will catch the
> exit status next time it happens.
>
> Yes, removing the metadata directory was the only way it was resolved.
> This happened on multiple hosts requiring the same resolution.
>
>
> On Thu, Feb 25, 2016 at 6:37 PM, Benjamin Mahler 
> wrote:
>
>> Feel free to create one. I don't have enough information to know what the
>> issue is without doing some further investigation, but if the situation you
>> described is accurate it seems like a there are two strange bugs:
>>
>> -the silent exit (do you not have the exit status?), and
>> -the flapping from ZK errors that needed the meta data directory to be
>> removed to resolve (are you convinced the removal of the meta directory is
>> what solved it?)
>>
>> It would be good to track these issues in case they crop up again.
>>
>> On Tue, Feb 23, 2016 at 2:51 PM, Sharma Podila 
>> wrote:
>>
>>> Hi Ben,
>>>
>>> Let me know if there is a new issue created for this, I would like to
>>> add myself to watch it.
>>> Thanks.
>>>
>>>
>>>
>>> On Wed, Feb 10, 2016 at 9:54 AM, Sharma Podila 
>>> wrote:
>>>
 Hi Ben,

 That is accurate, with one additional line:

 -Agent running fine with 0.24.1
 -Transient ZK issues, slave flapping with zookeeper_init failure
 -ZK issue resolved
 -Most agents stop flapping and function correctly
 -Some agents continue flapping, but silent exit after printing the
 detector.cpp:481 log line.
 -The agents that continue to flap repaired with manual removal of
 contents in mesos-slave's working dir



 On Wed, Feb 10, 2016 at 9:43 AM, Benjamin Mahler 
 wrote:

> Hey Sharma,
>
> I didn't quite follow the timeline of events here or how the agent
> logs you posted fit into the timeline of events. Here's how I interpreted:
>
> -Agent running fine with 0.24.1
> -Transient ZK issues, slave flapping with zookeeper_init failure
> -ZK issue resolved
> -Most agents stop flapping and function correctly
> -Some agents continue flapping, but silent exit after printing the
> detector.cpp:481 log line.
>
> Is this accurate? What is the exit code from the silent exit?
>
> On Tue, Feb 9, 2016 at 9:09 PM, Sharma Podila 
> wrote:
>
>> Maybe related, but, maybe different since a new process seems to find
>> the master leader and still aborts, never recovering with restarts until
>> work dir data is removed.
>> It is happening in 0.24.1.
>>
>>
>>
>>
>> On Tue, Feb 9, 2016 at 11:53 AM, Vinod Kone 
>> wrote:
>>
>>> MESOS-1326 was fixed in 0.19.0 (set the fix version now). But I
>>> guess you are saying it is somehow related but not exactly the same 
>>> issue?
>>>
>>> On Tue, Feb 9, 2016 at 11:46 AM, Raúl Gutiérrez Segalés <
>>> r...@itevenworks.net> wrote:
>>>
 On 9 February 2016 at 11:04, Sharma Podila 
 wrote:

> We had a few mesos agents stuck in an unrecoverable state after a
> transient ZK init error. Is this a known problem? I wasn't able to 
> find an
> existing jira item for this. We are on 0.24.1 at this time.
>
> Most agents were fine, except a handful. These handful of agents
> had their mesos-slave process constantly restarting. The .INFO 
> logfile had
> the following contents below, before the process exited, with no error
> messages. The restarts were happening constantly due to an existing 
> service
> keep alive strategy.
>
> To fix it, we manually stopped the service, removed the data in
> the working dir, and then restarted it. The mesos-slave process was 
> able to
> restart then. The manual intervention needed to resolve it is 
> problematic.
>
> Here's the contents of the various log files on the agent:
>
> The .INFO logfile for one of the restarts before mesos-slave
> process exited with no other error messages:
>
> Log file created at: 2016/02/09 02:12:48
> Running on machine: titusagent-main-i-7697a9c5
> Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg
> I0209 02:12:48.502403 97255 logging.cpp:172] INFO level logging
> started!
> I0209 02:12:48.502938 97255 main.cpp:185] Build: 2015-09-30
> 16:12:07 by builds
> I0209 02:12:48.502974 97255 main.cpp:187]

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

2016-03-07 Thread Jie Yu 
I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as well if
you guys plan to cut another RC

On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
daniel.osbo...@metaswitch.com> wrote:

> -1
>
> If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively
> small patch which restores Mesos' ability to extract Docker assigned IPs.
> This has been broken with Docker 1.10's release over  a month ago, and
> prevents service discovery and DNS from working.
>
> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
> RB# 43093: https://reviews.apache.org/r/43093/
>
> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as
> expected.
>
> Apologies for not bringing this to attention earlier.
>
> Thanks all,
> Dan
>
> -Original Message-
> From: Vinod Kone [mailto:vinodk...@apache.org]
> Sent: Thursday, March 3, 2016 5:44 PM
> To: dev ; user 
> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>
>
> 0.28.0 includes the following:
>
>
> 
>
>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> subsystem in
>
> Linux. The cgroups/net_cls isolator allows operators to provide network
>
>
> performance isolation and network segmentation for containers within a
> Mesos
>
> cluster. To enable the cgroups/net_cls isolator, append
> `cgroups/net_cls` to
>
> the `--isolation` flag when starting the slave. Please refer to
>
>
> docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4687] - The implementation of scalar resource values (e.g., "2.5
>
>
> CPUs") has changed. Mesos now reliably supports resources with up to
> three
>
> decimal digits of precision (e.g., "2.501 CPUs"); resources with more
> than
>
> three decimal digits of precision will be rounded. Internally,
> resource math
>
> is now done using a fixed-point format that supports three decimal
> digits of
>
> precision, and then converted to/from floating point for input and
> output,
>
> respectively. Frameworks that do their own resource math and manipulate
>
>
> fractional resources may observe differences in roundoff error and
> numerical
>
> precision.
>
>
>
>
>
>   * [MESOS-4479] - Reserved resources can now optionally include "labels".
>
>
> Labels are a set of key-value pairs that can be used to associate
> metadata
>
> with a reserved resource. For example, frameworks can use this feature
> to
>
> distinguish between two reservations for the same role at the same
> agent
>
> that are intended for different purposes.
>
>
>
>
>
>   * [MESOS-2840] - **Experimental** support for container images in Mesos
>
>
> containerizer (a.k.a. Unified Containerizer). This allows frameworks to
>
>
> launch Docker/Appc containers using Mesos containerizer without
> relying on
>
> docker daemon (engine) or rkt. The isolation of the containers is done
> using
>
> isolators. Please refer to docs/container-image.md for currently
> supported
>
> features and limitations.
>
>
>
>
>
>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This
>
>
> allows executors to send HTTP requests to the /api/v1/executor agent
>
>
> endpoint without the need for an executor driver. Please refer to
>
>
> docs/executor-http-api.md for more details.
>
>
>
>
>
> Additional API Changes:
>
>
>   * [MESOS-4066] - Agent should not return partial state when a request is
> made to /state endpoint during recovery.
>
>   * [MESOS-4547] - Introduce TASK_KILLING state.
>
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-3583] - Add stream IDs for HTTP schedulers.
>
>
> The CHANGELOG for the release is available at:
>
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc1
>
>
> 
>
>
> The candidate for Mesos 0.28.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz
>
>
> The tag to be voted on is 0.28.0-rc1:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.0-rc1
>
>
> The MD5 checksum of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.asc
>
>
> The PGP key used to

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

2016-03-07 Thread Greg Mann 
+1 (non-binding)

`make check` and `sudo make check` on OSX 10.10.5 and CentOS 7.1, with
libevent and SSL enabled.

All tests pass on CentOS 7.1

When running the sudo tests on OSX, three failures were observed:
ExamplesTest.JavaFramework is tracked by
https://issues.apache.org/jira/browse/MESOS-3582
FetcherCacheTest.LocalUncachedExtract and FetcherCacheHttpTest.HttpMixed:
these seem to be failing due to a lack of filesystem permissions. Since
this has only been observed on OSX, it doesn't look like a blocker to me. I
didn't find a ticket covering this specific failure, so I created one here:
https://issues.apache.org/jira/browse/MESOS-4890

On Mon, Mar 7, 2016 at 12:57 PM, Vinod Kone  wrote:

> Looks like there is a bunch of discussion around MESOS-4370 and RB# 43093.
> Kapil, as the shepherd, what is your take on the priority and readiness of
> this?
>
> On Mon, Mar 7, 2016 at 1:16 PM, Daniel Osborne <
> daniel.osbo...@metaswitch.com> wrote:
>
> > -1
> >
> > If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively
> > small patch which restores Mesos' ability to extract Docker assigned IPs.
> > This has been broken with Docker 1.10's release over  a month ago, and
> > prevents service discovery and DNS from working.
> >
> > Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
> > RB# 43093: https://reviews.apache.org/r/43093/
> >
> > I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as
> > expected.
> >
> > Apologies for not bringing this to attention earlier.
> >
> > Thanks all,
> > Dan
> >
> > -Original Message-
> > From: Vinod Kone [mailto:vinodk...@apache.org]
> > Sent: Thursday, March 3, 2016 5:44 PM
> > To: dev ; user 
> > Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
> >
> > Hi all,
> >
> >
> > Please vote on releasing the following candidate as Apache Mesos 0.28.0.
> >
> >
> > 0.28.0 includes the following:
> >
> >
> >
> 
> >
> >   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> > subsystem in
> >
> > Linux. The cgroups/net_cls isolator allows operators to provide
> network
> >
> >
> > performance isolation and network segmentation for containers within
> a
> > Mesos
> >
> > cluster. To enable the cgroups/net_cls isolator, append
> > `cgroups/net_cls` to
> >
> > the `--isolation` flag when starting the slave. Please refer to
> >
> >
> > docs/mesos-containerizer.md for more details.
> >
> >
> >
> >
> >
> >   * [MESOS-4687] - The implementation of scalar resource values (e.g.,
> "2.5
> >
> >
> > CPUs") has changed. Mesos now reliably supports resources with up to
> > three
> >
> > decimal digits of precision (e.g., "2.501 CPUs"); resources with more
> > than
> >
> > three decimal digits of precision will be rounded. Internally,
> > resource math
> >
> > is now done using a fixed-point format that supports three decimal
> > digits of
> >
> > precision, and then converted to/from floating point for input and
> > output,
> >
> > respectively. Frameworks that do their own resource math and
> manipulate
> >
> >
> > fractional resources may observe differences in roundoff error and
> > numerical
> >
> > precision.
> >
> >
> >
> >
> >
> >   * [MESOS-4479] - Reserved resources can now optionally include
> "labels".
> >
> >
> > Labels are a set of key-value pairs that can be used to associate
> > metadata
> >
> > with a reserved resource. For example, frameworks can use this
> feature
> > to
> >
> > distinguish between two reservations for the same role at the same
> > agent
> >
> > that are intended for different purposes.
> >
> >
> >
> >
> >
> >   * [MESOS-2840] - **Experimental** support for container images in Mesos
> >
> >
> > containerizer (a.k.a. Unified Containerizer). This allows frameworks
> to
> >
> >
> > launch Docker/Appc containers using Mesos containerizer without
> > relying on
> >
> > docker daemon (engine) or rkt. The isolation of the containers is
> done
> > using
> >
> > isolators. Please refer to docs/container-image.md for currently
> > supported
> >
> > features and limitations.
> >
> >
> >
> >
> >
> >   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API.
> This
> >
> >
> > allows executors to send HTTP requests to the /api/v1/executor agent
> >
> >
> > endpoint without the need for an executor driver. Please refer to
> >
> >
> > docs/executor-http-api.md for more details.
> >
> >
> >
> >
> >
> > Additional API Changes:
> >
> >
> >   * [MESOS-4066] - Agent should not return partial state when a request
> is
> > made to /state endpoint during recovery.
> >
> >   * [MESOS-4547] - Introduce TASK_KILLING state.
> >
> >
> >   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> > Scheduler API.
> >
> >   * [MESOS-4591] - Change the

Re: [VOTE] Release Apache Mesos 0.28.0 (rc1)

2016-03-07 Thread Vinod Kone 
Looks like there is a bunch of discussion around MESOS-4370 and RB# 43093.
Kapil, as the shepherd, what is your take on the priority and readiness of
this?

On Mon, Mar 7, 2016 at 1:16 PM, Daniel Osborne <
daniel.osbo...@metaswitch.com> wrote:

> -1
>
> If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively
> small patch which restores Mesos' ability to extract Docker assigned IPs.
> This has been broken with Docker 1.10's release over  a month ago, and
> prevents service discovery and DNS from working.
>
> Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
> RB# 43093: https://reviews.apache.org/r/43093/
>
> I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as
> expected.
>
> Apologies for not bringing this to attention earlier.
>
> Thanks all,
> Dan
>
> -Original Message-
> From: Vinod Kone [mailto:vinodk...@apache.org]
> Sent: Thursday, March 3, 2016 5:44 PM
> To: dev ; user 
> Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
>
>
> 0.28.0 includes the following:
>
>
> 
>
>   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> subsystem in
>
> Linux. The cgroups/net_cls isolator allows operators to provide network
>
>
> performance isolation and network segmentation for containers within a
> Mesos
>
> cluster. To enable the cgroups/net_cls isolator, append
> `cgroups/net_cls` to
>
> the `--isolation` flag when starting the slave. Please refer to
>
>
> docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4687] - The implementation of scalar resource values (e.g., "2.5
>
>
> CPUs") has changed. Mesos now reliably supports resources with up to
> three
>
> decimal digits of precision (e.g., "2.501 CPUs"); resources with more
> than
>
> three decimal digits of precision will be rounded. Internally,
> resource math
>
> is now done using a fixed-point format that supports three decimal
> digits of
>
> precision, and then converted to/from floating point for input and
> output,
>
> respectively. Frameworks that do their own resource math and manipulate
>
>
> fractional resources may observe differences in roundoff error and
> numerical
>
> precision.
>
>
>
>
>
>   * [MESOS-4479] - Reserved resources can now optionally include "labels".
>
>
> Labels are a set of key-value pairs that can be used to associate
> metadata
>
> with a reserved resource. For example, frameworks can use this feature
> to
>
> distinguish between two reservations for the same role at the same
> agent
>
> that are intended for different purposes.
>
>
>
>
>
>   * [MESOS-2840] - **Experimental** support for container images in Mesos
>
>
> containerizer (a.k.a. Unified Containerizer). This allows frameworks to
>
>
> launch Docker/Appc containers using Mesos containerizer without
> relying on
>
> docker daemon (engine) or rkt. The isolation of the containers is done
> using
>
> isolators. Please refer to docs/container-image.md for currently
> supported
>
> features and limitations.
>
>
>
>
>
>   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This
>
>
> allows executors to send HTTP requests to the /api/v1/executor agent
>
>
> endpoint without the need for an executor driver. Please refer to
>
>
> docs/executor-http-api.md for more details.
>
>
>
>
>
> Additional API Changes:
>
>
>   * [MESOS-4066] - Agent should not return partial state when a request is
> made to /state endpoint during recovery.
>
>   * [MESOS-4547] - Introduce TASK_KILLING state.
>
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
>
>   * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
>
>   * [MESOS-3583] - Add stream IDs for HTTP schedulers.
>
>
> The CHANGELOG for the release is available at:
>
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc1
>
>
> 
>
>
> The candidate for Mesos 0.28.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz
>
>
> The tag to be voted on is 0.28.0-rc1:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.0-rc1
>
>
> The MD5 checksum of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
>

RE: [VOTE] Release Apache Mesos 0.28.0 (rc1)

2016-03-07 Thread Daniel Osborne 
-1

If it doesn’t cause too much pain, I'm hoping we can squeeze a relatively small 
patch which restores Mesos' ability to extract Docker assigned IPs. This has 
been broken with Docker 1.10's release over  a month ago, and prevents service 
discovery and DNS from working.

Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
RB# 43093: https://reviews.apache.org/r/43093/

I've built 0.28.0-rc1 with this patch and can confirm that it fixes it as 
expected.

Apologies for not bringing this to attention earlier.

Thanks all,
Dan

-Original Message-
From: Vinod Kone [mailto:vinodk...@apache.org] 
Sent: Thursday, March 3, 2016 5:44 PM
To: dev ; user 
Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)

Hi all,


Please vote on releasing the following candidate as Apache Mesos 0.28.0.


0.28.0 includes the following:



  * [MESOS-4343] - A new cgroups isolator for enabling the net_cls subsystem in

Linux. The cgroups/net_cls isolator allows operators to provide network


performance isolation and network segmentation for containers within a Mesos

cluster. To enable the cgroups/net_cls isolator, append `cgroups/net_cls` to

the `--isolation` flag when starting the slave. Please refer to


docs/mesos-containerizer.md for more details.





  * [MESOS-4687] - The implementation of scalar resource values (e.g., "2.5


CPUs") has changed. Mesos now reliably supports resources with up to three

decimal digits of precision (e.g., "2.501 CPUs"); resources with more than

three decimal digits of precision will be rounded. Internally, resource math

is now done using a fixed-point format that supports three decimal digits of

precision, and then converted to/from floating point for input and output,

respectively. Frameworks that do their own resource math and manipulate


fractional resources may observe differences in roundoff error and numerical

precision.





  * [MESOS-4479] - Reserved resources can now optionally include "labels".


Labels are a set of key-value pairs that can be used to associate metadata

with a reserved resource. For example, frameworks can use this feature to

distinguish between two reservations for the same role at the same agent

that are intended for different purposes.





  * [MESOS-2840] - **Experimental** support for container images in Mesos


containerizer (a.k.a. Unified Containerizer). This allows frameworks to


launch Docker/Appc containers using Mesos containerizer without relying on

docker daemon (engine) or rkt. The isolation of the containers is done using

isolators. Please refer to docs/container-image.md for currently supported

features and limitations.





  * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API. This


allows executors to send HTTP requests to the /api/v1/executor agent


endpoint without the need for an executor driver. Please refer to


docs/executor-http-api.md for more details.





Additional API Changes:


  * [MESOS-4066] - Agent should not return partial state when a request is made 
to /state endpoint during recovery.

  * [MESOS-4547] - Introduce TASK_KILLING state.


  * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1 Scheduler 
API.

  * [MESOS-4591] - Change the object of ReserveResources and CreateVolume ACLs 
to `roles`.

  * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1 Scheduler 
API.

  * [MESOS-4591] - Change the object of ReserveResources and CreateVolume ACLs 
to `roles`.

  * [MESOS-3583] - Add stream IDs for HTTP schedulers.


The CHANGELOG for the release is available at:

https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.0-rc1




The candidate for Mesos 0.28.0 release is available at:

https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz


The tag to be voted on is 0.28.0-rc1:

https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.0-rc1


The MD5 checksum of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.md5


The signature of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/0.28.0-rc1/mesos-0.28.0.tar.gz.asc


The PGP key used to sign the release is here:

https://dist.apache.org/repos/dist/release/mesos/KEYS


The JAR is up in Maven in a staging repository here:

https://repository.apache.org/content/repositories/orgapachemesos-1112


Please vote on releasing this package as Apache Mesos 0.28.0!


The vote is open until Tue Mar  10 17:00:00 PST 2016 and passes if a majority 
of at least 3 +1 PMC votes are cast.


[ ] +1 Release this package as Apache Mesos 0.28.0

[ ] -1 Do not release this package

Marathon SSLHandshakeException

2016-03-07 Thread Alberto del Barrio 

Hi all,

I am playing with SSL in Marathon 0.10 and Mesos 0.25.
I could enable SSL in Marathon, creating a self-signed certificate and 
importing it into a java keystore. I did that from one of the 3 machines 
where Marathon runs.
After, i copied the jks file to the two other machines, and restart 
Marathon passing the corresponding command line attributes.

Now my situation is:
 - When browsing the web UI of the master, I am able to see the list of 
running apps.
 - When browsing the web UI of one slave, I can't see any app running. 
The logs of the process are showing 
"java.security.cert.CertificateException: No subject alternative DNS 
name matching master.name.com found"


So, the issue is when the slave redirects to the master.
If I move the master service to other machine, I experience the same 
issue: it works in the master but not in the salve.
I was reading this troubleshooting guide 
, but 
it couldn't help me.


Does anyone have experienced the same problem?

RE: mesos master 0.27.1 needs g++ to execute ?

2016-03-07 Thread kr di 
Thanks, I am upgrading from 0.25 directly to 0.27.1.  If this is the was mesos 
is going (i.e. relink) then I’ll manage.  I’ll look into lt-mesos-master



Sent from Mail for Windows 10

From: haosdent
Sent: Monday, March 7, 2016 7:31 AM
To: user
Subject: Re: mesos master 0.27.1 needs g++ to execute ?

If you use automake tools to build mesos, the `mesos-master` actually is a
warpper of "build/src/.libs/lt-mesos-master". And in the `mesos-master.sh`,
g++ is needed when relink. Not only 0.27.1, but also before 0.27.1, g++ is
always needed when relink. You could trigger relink after remove
"build/src/.libs/lt-mesos-master".

On Mon, Mar 7, 2016 at 7:43 PM, kr di  wrote:

> I am not doing the standard rpm, but am building from source and following
> their directions for running the mesos master.  Mesos 0.25 runs fine
> -non-docker and docker and doesn’t need g++ to run.  I can also run mesos
> master 0.27.1 fine non-docker and docker; I just want to know why mesos
> master 0.27.1 needs g++.
>
>
>
> Is this more a question for the developer list?
>
>
>
> Thanks,
>
>
>
> Mark
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *haosdent 
> *Sent: *Sunday, March 6, 2016 8:03 PM
> *To: *user 
>
> *Subject: *Re: mesos master 0.27.1 needs g++ to execute ?
>
>
> I think you should not run it by "build/bin/xxx.sh", it may only work in
> your build machine.
> You could try install it by deb/rpm
> http://open.mesosphere.com/downloads/mesos/#apache-mesos-0.27.0
>
> On Mon, Mar 7, 2016 at 8:51 AM, kr di  wrote:
>
> Sure – sorry.  I did two ones, one before I added gcc and the other after
> I added gcc:
>
>
>
> The following is if I simply use the same dockerfile for mesos 0.27.1 as I
> used with mesos 0.25 (which executed and worked fine without error):
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --c1uster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,1O.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work
> /home/ec2-user/mm.dev/mesos-0.27.1/build/src/mesos-master: line 202: g++:
> command not found
>
>
>
> The following is the error from mesos 0.27.1 if I add gcc-c++ to the
> docker container:
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --cluster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,10.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work g++: error:
> /usr/lib64/libaprutil-1.so: No such file or directory g++: error:
> /usr/lib64/libapr-1.so: No such file or directory
>
> 1
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Klaus Ma 
> *Sent: *Sunday, March 6, 2016 8:17 AM
> *To: *user@mesos.apache.org
> *Subject: *Re: mesos master 0.27.1 needs g++ to execute ?
>
>
> Hi KR,
>
> Can you share the error message?
>
> 
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform OpenSource Technology, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>
> On Sun, Mar 6, 2016 at 8:22 PM, kr di  wrote:
>
> I have dockerized amy compiled version of mesos master for version 0.25
> successfully.  In moving closer to production, I am upgrading to 0.27.1.
> However, in dockerizing 0.27.1, the mesos master seems to need g++ (plus a
> few libraries) to execute which was not the case with mesos 0.25.  I am not
> speaking of compiling mesos.  I successfully downloaded mesos tar file and
> compiled mesos (0.25 and 0.27.1) on RHEL 7.2.  Mesos master 0.27.1 runs
> without issues on my system with development tools.
>
>
>
> The issue is that I am hesitate to put development tools on a production
> system without understanding why g++ is needed. Could someone briefly
> explain why I need g++ to run mesos 0.27.1 (and maybe why mesos 0.25 did
> not require g++) to run? And whether there is a work-around to not having
> development tools (g++) for mesos master?
>
>
>
> Awesome software btw.
>
>
>
> Thank you,
>
>
>
> KR
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>



--
Best Regards,
Haosdent Huang

Re: mesos master 0.27.1 needs g++ to execute ?

2016-03-07 Thread haosdent 
If you use automake tools to build mesos, the `mesos-master` actually is a
warpper of "build/src/.libs/lt-mesos-master". And in the `mesos-master.sh`,
g++ is needed when relink. Not only 0.27.1, but also before 0.27.1, g++ is
always needed when relink. You could trigger relink after remove
"build/src/.libs/lt-mesos-master".

On Mon, Mar 7, 2016 at 7:43 PM, kr di  wrote:

> I am not doing the standard rpm, but am building from source and following
> their directions for running the mesos master.  Mesos 0.25 runs fine
> -non-docker and docker and doesn’t need g++ to run.  I can also run mesos
> master 0.27.1 fine non-docker and docker; I just want to know why mesos
> master 0.27.1 needs g++.
>
>
>
> Is this more a question for the developer list?
>
>
>
> Thanks,
>
>
>
> Mark
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *haosdent 
> *Sent: *Sunday, March 6, 2016 8:03 PM
> *To: *user 
>
> *Subject: *Re: mesos master 0.27.1 needs g++ to execute ?
>
>
> I think you should not run it by "build/bin/xxx.sh", it may only work in
> your build machine.
> You could try install it by deb/rpm
> http://open.mesosphere.com/downloads/mesos/#apache-mesos-0.27.0
>
> On Mon, Mar 7, 2016 at 8:51 AM, kr di  wrote:
>
> Sure – sorry.  I did two ones, one before I added gcc and the other after
> I added gcc:
>
>
>
> The following is if I simply use the same dockerfile for mesos 0.27.1 as I
> used with mesos 0.25 (which executed and worked fine without error):
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --c1uster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,1O.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work
> /home/ec2-user/mm.dev/mesos-0.27.1/build/src/mesos-master: line 202: g++:
> command not found
>
>
>
> The following is the error from mesos 0.27.1 if I add gcc-c++ to the
> docker container:
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --cluster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,10.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work g++: error:
> /usr/lib64/libaprutil-1.so: No such file or directory g++: error:
> /usr/lib64/libapr-1.so: No such file or directory
>
> 1
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Klaus Ma 
> *Sent: *Sunday, March 6, 2016 8:17 AM
> *To: *user@mesos.apache.org
> *Subject: *Re: mesos master 0.27.1 needs g++ to execute ?
>
>
> Hi KR,
>
> Can you share the error message?
>
> 
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform OpenSource Technology, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>
> On Sun, Mar 6, 2016 at 8:22 PM, kr di  wrote:
>
> I have dockerized amy compiled version of mesos master for version 0.25
> successfully.  In moving closer to production, I am upgrading to 0.27.1.
> However, in dockerizing 0.27.1, the mesos master seems to need g++ (plus a
> few libraries) to execute which was not the case with mesos 0.25.  I am not
> speaking of compiling mesos.  I successfully downloaded mesos tar file and
> compiled mesos (0.25 and 0.27.1) on RHEL 7.2.  Mesos master 0.27.1 runs
> without issues on my system with development tools.
>
>
>
> The issue is that I am hesitate to put development tools on a production
> system without understanding why g++ is needed. Could someone briefly
> explain why I need g++ to run mesos 0.27.1 (and maybe why mesos 0.25 did
> not require g++) to run? And whether there is a work-around to not having
> development tools (g++) for mesos master?
>
>
>
> Awesome software btw.
>
>
>
> Thank you,
>
>
>
> KR
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Best Regards,
Haosdent Huang

RE: mesos master 0.27.1 needs g++ to execute ?

2016-03-07 Thread kr di 
I am not doing the standard rpm, but am building from source and following 
their directions for running the mesos master.  Mesos 0.25 runs fine  
-non-docker and docker and doesn’t need g++ to run.  I can also run mesos 
master 0.27.1 fine non-docker and docker; I just want to know why mesos master 
0.27.1 needs g++.

Is this more a question for the developer list?

Thanks,

Mark

Sent from Mail for Windows 10

From: haosdent
Sent: Sunday, March 6, 2016 8:03 PM
To: user
Subject: Re: mesos master 0.27.1 needs g++ to execute ?

I think you should not run it by "build/bin/xxx.sh", it may only work in
your build machine.
You could try install it by deb/rpm
http://open.mesosphere.com/downloads/mesos/#apache-mesos-0.27.0

On Mon, Mar 7, 2016 at 8:51 AM, kr di  wrote:

> Sure – sorry.  I did two ones, one before I added gcc and the other after
> I added gcc:
>
>
>
> The following is if I simply use the same dockerfile for mesos 0.27.1 as I
> used with mesos 0.25 (which executed and worked fine without error):
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --c1uster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,1O.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work
> /home/ec2-user/mm.dev/mesos-0.27.1/build/src/mesos-master: line 202: g++:
> command not found
>
>
>
> The following is the error from mesos 0.27.1 if I add gcc-c++ to the
> docker container:
>
>
>
> + exec /home/ec2-user/mm.dev/mesos/build/bin/mesos-master.sh
> --Iog_dir=/data/mesos/logs --no-hostname_lookup
> --cluster=marks-mm-test_Mesos_master-zk=zk://10.6.250.84:2181,
> 10.6.250.83:2181,10.6.250.82:2181/mesos --ip=172.1.0.4
> -advertiseJp=1O.6.250.82 --quorum=2 --work_dir=/data/mesos/work g++: error:
> /usr/lib64/libaprutil-1.so: No such file or directory g++: error:
> /usr/lib64/libapr-1.so: No such file or directory
>
> 1
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Klaus Ma 
> *Sent: *Sunday, March 6, 2016 8:17 AM
> *To: *user@mesos.apache.org
> *Subject: *Re: mesos master 0.27.1 needs g++ to execute ?
>
>
> Hi KR,
>
> Can you share the error message?
>
> 
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform OpenSource Technology, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>
> On Sun, Mar 6, 2016 at 8:22 PM, kr di  wrote:
>
> I have dockerized amy compiled version of mesos master for version 0.25
> successfully.  In moving closer to production, I am upgrading to 0.27.1.
> However, in dockerizing 0.27.1, the mesos master seems to need g++ (plus a
> few libraries) to execute which was not the case with mesos 0.25.  I am not
> speaking of compiling mesos.  I successfully downloaded mesos tar file and
> compiled mesos (0.25 and 0.27.1) on RHEL 7.2.  Mesos master 0.27.1 runs
> without issues on my system with development tools.
>
>
>
> The issue is that I am hesitate to put development tools on a production
> system without understanding why g++ is needed. Could someone briefly
> explain why I need g++ to run mesos 0.27.1 (and maybe why mesos 0.25 did
> not require g++) to run? And whether there is a work-around to not having
> development tools (g++) for mesos master?
>
>
>
> Awesome software btw.
>
>
>
> Thank you,
>
>
>
> KR
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
>
>


--
Best Regards,
Haosdent Huang