Re: 1.0 Release Candidate

[Zameer Manji]

I might be in the minority here, but I think cutting an RC for 1.0 right
now is very aggressive. Does there exist even a single framework that uses
the Scheduler HTTP API or the Executor HTTP API? Does anyone even use these
APIs in production? Is there a single entity that uses the Operator API to
manage agents?

I think cutting an RC right now is 100% premature until the community can
provide clear answers to these questions.

I think Mesos project has been historically successful because its features
were developed in a slow methodical manner and then battle tested by at
least a user before the feature was declared 'stable' and ready for use for
everyone. I think not following those steps here for the HTTP APIs is a
huge error.

On Wed, May 25, 2016 at 12:51 PM, Vinod Kone  wrote:

> Post 1.0. Jie might be able to shed more light regarding the plans for
> Docker Containerizer.
>
> On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
> jeffschroe...@computer.org> wrote:
>
>> Does this mean the work to deprecate the docker containerizer will be
>> post-1.0, or have those plans changed?
>>
>>
>> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>>
>>> Hi folks,
>>>
>>> As discussed in the previous community sync, we plan to cut a release
>>> candidate for our next release (1.0) early next week.
>>>
>>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>>> MESOS-338  for
>>> blocking issues. We got some great design and testing feedback for the v1
>>> scheduler and executor APIs. Please do the same for the in-progress v1
>>> operator API
>>> 
>>> .
>>>
>>> Since this is a 1.0, we would like to do the release a little
>>> differently.
>>>
>>> First, the voting period for vetting the release candidate would be a
>>> few weeks (2-3 weeks) instead of the typical 3 days.
>>>
>>> Second, we are wiling to make major changes (scalability fixes, API
>>> fixes) if there are any issues reported by the community.
>>>
>>> We are doing these because we really want the community to thoroughly
>>> test the 1.0 release and give feedback.
>>>
>>> Thanks,
>>>
>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>

Re: Round robin DNS zookeeper record

[Joseph Wu]

Mesos passes the list inside between "zk://" and the first "/" directly
into Zookeeper's C bindings.
I'm not familiar enough with the Zookeeper API to say for certain, but it
looks like this *does* support your round-robin scheme.
You can double check here:
https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L620-L650


As for your other questions:

1) When the ZK connection is lost, Mesos will re-resolve the address as of
MESOS-4546 (https://issues.apache.org/jira/browse/MESOS-4546).

2) Looks like ZK rotates between servers.  When one server returns an
error, it tries the next one, in a circle.
Increment code:
https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L1248
Connection code:
https://github.com/apache/zookeeper/blob/release-3.4.8/src/c/src/zookeeper.c#L1578-L1580

On Wed, May 25, 2016 at 3:50 PM, Zhitao Li  wrote:

> Hi,
>
> Can someone confirm whether the zookeeper library Mesos is using well
> supports round robin DNS?
>
> For example,  if I have a round robin DNS entry `zookeeper-mesos-dc` which
> resolves to five A records, would the --zk flag value `
> zk://zookeeper-mesos-dc:2181/mesos` work on master, agents and any
> framework using libmesos driver?
>
> Also:
> 1. What happens if one of the A records changes in the DNS record? Do I
> need to restart related Mesos processes?
> 2. What happens if one of the A records is not responsive (e.g. underlying
> zookeeper server is dead)? Is the zookeeper library capable to avoid
> the bad server?
>
> Some pointer for me to find out the answer individually is also greatly
> appreciated.
>
> Thanks!
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: 1.0 Release Candidate

[Jeff Schroeder]

Does this mean the work to deprecate the docker containerizer will be
post-1.0, or have those plans changed?

On Wednesday, May 25, 2016, Vinod Kone  wrote:

> Hi folks,
>
> As discussed in the previous community sync, we plan to cut a release
> candidate for our next release (1.0) early next week.
>
> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> MESOS-338  for blocking
> issues. We got some great design and testing feedback for the v1 scheduler
> and executor APIs. Please do the same for the in-progress v1 operator API
> 
> .
>
> Since this is a 1.0, we would like to do the release a little differently.
>
> First, the voting period for vetting the release candidate would be a few
> weeks (2-3 weeks) instead of the typical 3 days.
>
> Second, we are wiling to make major changes (scalability fixes, API fixes)
> if there are any issues reported by the community.
>
> We are doing these because we really want the community to thoroughly test
> the 1.0 release and give feedback.
>
> Thanks,
>


-- 
Text by Jeff, typos by iPhone

Round robin DNS zookeeper record

[Zhitao Li]

Hi,

Can someone confirm whether the zookeeper library Mesos is using well
supports round robin DNS?

For example,  if I have a round robin DNS entry `zookeeper-mesos-dc` which
resolves to five A records, would the --zk flag value `
zk://zookeeper-mesos-dc:2181/mesos` work on master, agents and any
framework using libmesos driver?

Also:
1. What happens if one of the A records changes in the DNS record? Do I
need to restart related Mesos processes?
2. What happens if one of the A records is not responsive (e.g. underlying
zookeeper server is dead)? Is the zookeeper library capable to avoid
the bad server?

Some pointer for me to find out the answer individually is also greatly
appreciated.

Thanks!


-- 
Cheers,

Zhitao Li

Re: Memory leak in libmesos + patch

[Elizabeth Lingg]

Thanks for the quick turn around on reviewing and merging this important
bug fix.

-Elizabeth

On Tue, May 24, 2016 at 6:04 PM, Jie Yu  wrote:

> Dario,
>
> Thanks for reporting. We'll take a look that asap.
>
> - Jie
>
> On Tue, May 24, 2016 at 5:56 PM, Dario Rexin  wrote:
>
> > Hi all,
> >
> > we recently started observing abnormal memory growth in our schedulers
> > after deploying a new Mesos version and after looking into it discovered
> a
> > memory leak in libmesos. The details are in the JIRA.
> >
> > It would be great if someone could review the patch.
> >
> > JIRA: https://issues.apache.org/jira/browse/MESOS-5449 <
> > https://issues.apache.org/jira/browse/MESOS-5449>
> > Review Board: https://reviews.apache.org/r/47804/ <
> > https://reviews.apache.org/r/47804/>
> >
> > Thanks,
> > Dario
>

Re: 1.0 Release Candidate

[Vinod Kone]

Post 1.0. Jie might be able to shed more light regarding the plans for
Docker Containerizer.

On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Jie Yu]

Jeff,

Yes, deprecating the docker containerizer will be post-1.0. The plan has
not changed. In fact, we are making very good progress on the unified
containerizer side (see this doc
).

We'll continue to support Docker containerizer, but at a reduced pace. In
other words, any new features will be supported in the unified
containerizer first. We will still do bug fixes for the docker
containerizer.

Let us know if you have any comments or concerns on that. Thanks!

- Jie

On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Joseph Wu]

I'm guessing you mean the "medium term" bullet point on the Roadmap (
https://cwiki.apache.org/confluence/display/MESOS/Roadmap):

>
>- Deprecate Docker containerizer (in favor of Unified containerizer w/
>Docker support)
>
> This was never meant to be done as part of the 1.0 release.  I'm sure the
folks working on the unified containerizer can tell you their exact plans.


On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder  wrote:

> Does this mean the work to deprecate the docker containerizer will be
> post-1.0, or have those plans changed?
>
>
> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> As discussed in the previous community sync, we plan to cut a release
>> candidate for our next release (1.0) early next week.
>>
>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
>> MESOS-338  for blocking
>> issues. We got some great design and testing feedback for the v1 scheduler
>> and executor APIs. Please do the same for the in-progress v1 operator API
>> 
>> .
>>
>> Since this is a 1.0, we would like to do the release a little
>> differently.
>>
>> First, the voting period for vetting the release candidate would be a few
>> weeks (2-3 weeks) instead of the typical 3 days.
>>
>> Second, we are wiling to make major changes (scalability fixes, API
>> fixes) if there are any issues reported by the community.
>>
>> We are doing these because we really want the community to thoroughly
>> test the 1.0 release and give feedback.
>>
>> Thanks,
>>
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: 1.0 Release Candidate

[Vinod Kone]

As part of this, I'm going to:

1) Update configure.ac and CMakeLists to point to 1.0.0 version. Note that
if someone is building off master, this might be a little weird because up
until this change their builds would've 0.29.0 version and after this
change it would be 1.0.0. But I guess it's unavoidable.

2) Transition the issues with Fix Version "0.29.0" to "1.0.0". I will make
sure to turn off JIRA notification emails for this change to avoid spamming
issues@.

Thanks,

On Wed, May 25, 2016 at 8:52 AM, Vinod Kone  wrote:

> Hi folks,
>
> As discussed in the previous community sync, we plan to cut a release
> candidate for our next release (1.0) early next week.
>
> 1.0 is mainly centered around new APIs for Mesos. Please take a look at
> MESOS-338  for blocking
> issues. We got some great design and testing feedback for the v1 scheduler
> and executor APIs. Please do the same for the in-progress v1 operator API
> 
> .
>
> Since this is a 1.0, we would like to do the release a little differently.
>
> First, the voting period for vetting the release candidate would be a few
> weeks (2-3 weeks) instead of the typical 3 days.
>
> Second, we are wiling to make major changes (scalability fixes, API fixes)
> if there are any issues reported by the community.
>
> We are doing these because we really want the community to thoroughly test
> the 1.0 release and give feedback.
>
> Thanks,
>

1.0 Release Candidate

[Vinod Kone]

Hi folks,

As discussed in the previous community sync, we plan to cut a release
candidate for our next release (1.0) early next week.

1.0 is mainly centered around new APIs for Mesos. Please take a look at
MESOS-338  for blocking
issues. We got some great design and testing feedback for the v1 scheduler
and executor APIs. Please do the same for the in-progress v1 operator API

.

Since this is a 1.0, we would like to do the release a little differently.

First, the voting period for vetting the release candidate would be a few
weeks (2-3 weeks) instead of the typical 3 days.

Second, we are wiling to make major changes (scalability fixes, API fixes)
if there are any issues reported by the community.

We are doing these because we really want the community to thoroughly test
the 1.0 release and give feedback.

Thanks,

[GitHub] mesos pull request: Add Livespotting into powered-by-mesos.md

[jstabenow]

Github user jstabenow commented on the pull request:

https://github.com/apache/mesos/pull/106#issuecomment-221534774
  
@tillt thanks :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request: Add CMCRC to powered-by-mesos.md

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/108


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request: Add CMCRC to powered-by-mesos.md

[tillt]

Github user tillt commented on the pull request:

https://github.com/apache/mesos/pull/108#issuecomment-221532921
  
Committed as:
```
commit b33e780909561e07b377c9836c43b65117e98630
Author: Spritekin 
Date:   Wed May 25 12:19:34 2016 +0200

Added CMCRC to powered-by-mesos.md.

This closes #108
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request: Add Livespotting into powered-by-mesos.md

[tillt]

Github user tillt commented on the pull request:

https://github.com/apache/mesos/pull/106#issuecomment-221533453
  
Committed as:

```
commit 71b47658e411456df4a34491ea82bd4115f70479
Author: Jan Stabenow 
Date:   Wed May 25 12:23:30 2016 +0200

Add Livespotting into powered-by-mesos.md.

This closes #106
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] mesos pull request: Add Livespotting into powered-by-mesos.md

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/106


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Mesos Modules callbacks

[vzcambria]

I've found net-modules [1] helpful for a network isolation module.  
Instructions on how to install just the isolation module (and not all 
the calico stuff) are in a pull request.


[1] https://github.com/mesosphere/net-modules

On 05/25/2016 01:17 AM, Guangya Liu wrote:

Hi ct,

There are not too much document for this, but you can refer to the
following as reference and this may help.

1)
https://github.com/apache/mesos/blob/master/docs/networking-for-mesos-managed-containers.md#writing-a-custom-network-isolator-module
2)
https://github.com/apache/mesos/blob/master/include/mesos/slave/isolator.hpp

Thanks,

Guangya

On Wed, May 25, 2016 at 12:09 PM, ct clmsn  wrote:


I'm in the midst of writing a mesos module and wanted to know if there was
documentation available (in source, or html, or in proposals) that
explained the callbacks and the order in which they are called (prepare,
recover, isolate, update). Thanks in advance!

ct