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

[Guangya Liu]

+1 to this.

Only one minor comment: I saw that there are indeed someone using mesos
CLI, such as `mesos ps` etc. I did minor enhancement for mesos CLI recently
to improve debug-ability, it would be great if we can have those in 0.28.2.

The following are the three patches for mesos CLI enhancement:
https://reviews.apache.org/r/47636/ Fixed some coding error in mesos-ps.
https://reviews.apache.org/r/47693/ Added more error info for mesos ps.
https://reviews.apache.org/r/47711/ Added more verbose message when mesos
command encouter error.

Thanks,

Guangya

On Mon, May 30, 2016 at 7:53 AM, Jie Yu  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.28.2.
>
>
> 0.28.2 is a bug fix release. It includes the following:
>
> 
> ** Bug
>   * [MESOS-4705] - Linux 'perf' parsing logic may fail when OS
> distribution has perf backports.
>   * [MESOS-5239] - Persistent volume DockerContainerizer support assumes
> proper mount propagation setup on the host.
>   * [MESOS-5253] - Isolator cleanup should not be invoked if they are not
> prepared yet.
>   * [MESOS-5282] - Destroy container while provisioning volume images may
> lead to a race.
>   * [MESOS-5312] - Env `MESOS_SANDBOX` is not set properly for command
> tasks that changes rootfs.
>   * [MESOS-4885] - Unzip should force overwrite.
>   * [MESOS-5449] - Memory leak in SchedulerProcess.declineOffer.
>   * [MESOS-5380] - Killing a queued task can cause the corresponding
> command executor to never terminate.
>
> ** Improvement
>   * [MESOS-5307] - Sandbox mounts should not be in the host mount
> namespace.
>
> 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.2-rc1
>
> 
>
> The candidate for Mesos 0.28.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.tar.gz
>
> The tag to be voted on is 0.28.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.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-1140
>
> Please vote on releasing this package as Apache Mesos 0.28.2!
>
> The vote is open until Wed Jun  1 16:51:42 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.28.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
> - Jie
>

[VOTE] Release Apache Mesos 0.28.2 (rc1)

[Jie Yu]

Hi all,

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


0.28.2 is a bug fix release. It includes the following:

** Bug
  * [MESOS-4705] - Linux 'perf' parsing logic may fail when OS distribution
has perf backports.
  * [MESOS-5239] - Persistent volume DockerContainerizer support assumes
proper mount propagation setup on the host.
  * [MESOS-5253] - Isolator cleanup should not be invoked if they are not
prepared yet.
  * [MESOS-5282] - Destroy container while provisioning volume images may
lead to a race.
  * [MESOS-5312] - Env `MESOS_SANDBOX` is not set properly for command
tasks that changes rootfs.
  * [MESOS-4885] - Unzip should force overwrite.
  * [MESOS-5449] - Memory leak in SchedulerProcess.declineOffer.
  * [MESOS-5380] - Killing a queued task can cause the corresponding
command executor to never terminate.

** Improvement
  * [MESOS-5307] - Sandbox mounts should not be in the host mount namespace.

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.2-rc1


The candidate for Mesos 0.28.2 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.tar.gz

The tag to be voted on is 0.28.2-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.28.2-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.28.2-rc1/mesos-0.28.2.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-1140

Please vote on releasing this package as Apache Mesos 0.28.2!

The vote is open until Wed Jun  1 16:51:42 PDT 2016 and passes if a
majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.28.2
[ ] -1 Do not release this package because ...

Thanks,
- Jie

Re: 0.28.2

[Jie Yu]

OK, looks like no one volunteer for 0.27.3 and 0.26.2. Therefore, I'll be
the release manager for these two release as well. Will try to cut right
after MesosCon.

- Jie

On Fri, May 27, 2016 at 9:38 AM, Jie Yu  wrote:

> Any other committers have cycles for point release 0.27.3 and 0.26.2? If
> not, I'll take on it.
>
> - Jie
>
> On Fri, May 27, 2016 at 8:26 AM, Roger Ignazio  wrote:
>
>> Hey Jie,
>>
>> Will you also be handling the releases for 0.27.3 and 0.26.2 at the same
>> time? I've been waiting for this particular fix to land:
>> https://issues.apache.org/jira/browse/MESOS-4705.
>>
>> Thanks!
>>
>> -- Roger
>>
>> On Tue, May 24, 2016 at 9:04 AM, Jie Yu  wrote:
>>
>>> Hi folks,
>>>
>>> According to our release schedule, we should be cutting point release
>>> for 0.28.x. I volunteer to be the release manager. Vinod and Ben already
>>> started a branch (0.28.x) in the repo, so it's just a matter of cutting it.
>>> If you have any patch that you want to backport into 0.28.2, please let me
>>> know asap. I plan to cut it this Thursday.
>>>
>>> Thanks,
>>> - Jie
>>>
>>
>>
>

[GitHub] mesos pull request: Slave/Agent rename in diagrams.

[guoger]

GitHub user guoger opened a pull request:

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

Slave/Agent rename in diagrams.

Diagrams under docs/images are renamed.

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

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/guoger/mesos MESOS-5407-diagrams

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/109.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #109


commit e1b087b75b4af62d33360b5145b6dee75b3d887c
Author: Jay Guo 
Date:   2016-05-26T17:03:28Z

Slave/Agent rename in diagrams.

Diagrams under docs/images are renamed.

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




---
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: Slave/Agent rename in diagrams.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: 1.0 Release Candidate

[tommy xiao]

cool.

2016-05-29 19:03 GMT+08:00 haosdent :

> +1s
>
> On Sun, May 29, 2016 at 7:01 PM, Klaus Ma  wrote:
>
>> v1.0, exciting :).
>>
>> 
>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
>> Platform OpenSource Technology, STG, IBM GCG
>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>>
>>
>> > Date: Sun, 29 May 2016 02:31:47 -0700
>> > Subject: Re: 1.0 Release Candidate
>> > From: a...@mesosphere.io
>> > To: u...@mesos.apache.org
>> > CC: vinodk...@apache.org; dev@mesos.apache.org
>>
>> >
>> > FYI, I made an alternate 1.0 release dashboard with a longer timeframe
>> for
>> > the created vs. resolved chart, and added a couple of my favorite
>> widgets.
>> > Feel free to use anything you find helpful.
>> >
>> >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256
>> >
>> > On Thu, May 26, 2016 at 9:44 PM, Vinod Kone 
>> wrote:
>> >
>> > > This is the release dashboard:
>> > >
>> > >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>> > >
>> > > *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is
>> not a
>> > > blocker for 0.29.0/1.0 release, please unset the fix version.
>> > >
>> > > On Thu, May 26, 2016 at 3:44 PM, Vinod Kone 
>> wrote:
>> > >
>> > >> Thanks for asking the questions Zameer. Wanted to give some
>> clarification
>> > >> regarding the thought process for releasing 1.0.
>> > >>
>> > >> The reason for cutting a 1.0, is because we want to signal that the
>> > >> Mesos project has reached a level of maturity to the wider
>> community. Among
>> > >> other things we are confident at this point that the *foundations*
>> we laid
>> > >> for the new APIs are mature and could be evolved in a backwards
>> compatible
>> > >> way. We laid the foundations almost an year ago (at last MesosCon)
>> and
>> > >> since then have been busy implementing the backend to drive the API.
>> Even
>> > >> the newly released design doc for the operator API is built on the
>> same
>> > >> foundations as the scheduler/executor APIs. While we have been
>> tweaking the
>> > >> API backend for a while now the API definitions have mostly stayed
>> the
>> > >> same. Part of the reason it took this long is because we really
>> wanted to
>> > >> be sure the basic building blocks were solid.
>> > >>
>> > >> MesosCon is a great opportunity for us to drum up excitement about
>> the
>> > >> new APIs and invite them to start using/testing it. Like any other
>> OSS
>> > >> project, as people and organizations start using the new APIs in
>> staging
>> > >> and production, we will make stability and implementation
>> improvements. The
>> > >> long period for the RC will also help catching issues with API
>> foundations
>> > >> themselves. We have had a bit of chicken and egg problem having
>> people
>> > >> consume the new APIs because most don't want to use it in production
>> unless
>> > >> it is declared production ready and we can't call it production
>> ready until
>> > >> someone uses them in production.
>> > >>
>> > >> Having said all that stability and production readiness is paramount
>> for
>> > >> the project. That is never going to change. In the case of the new
>> APIs,
>> > >> we have developed C++ frameworks using the new APIs and having been
>> running
>> > >> them as part of ASF CI for months now. Mesosphere, for example, also
>> has an
>> > >> internal cluster where frameworks using these new APIs have been
>> baking for
>> > >> a while and had done (and doing) rigorous tests (network partitions,
>> > >> scaling tests, functional tests). Community members from IBM have
>> also been
>> > >> instrumental in testing the new APIs. We are hoping after 1.0 more
>> people
>> > >> would be willing and excited to consume these new APIs and stress
>> test in
>> > >> their environments.
>> > >>
>> > >> At the end of the day, while new APIs are an important part of Mesos
>> 1.0
>> > >> it's not the only reason for cutting a 1.0 release. Mesos has a slew
>> of
>> > >> exciting features and a thriving eco system and we would love to
>> have more
>> > >> people excited and get a taste of it. 1.0 is just a start...
>> > >>
>> > >> Hope that helps,
>> > >>
>> > >>
>> > >> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji 
>> wrote:
>> > >>
>> > >>> 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 

Re: 1.0 Release Candidate

[Adam Bordelon]

FYI, I made an alternate 1.0 release dashboard with a longer timeframe for
the created vs. resolved chart, and added a couple of my favorite widgets.
Feel free to use anything you find helpful.

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256

On Thu, May 26, 2016 at 9:44 PM, Vinod Kone  wrote:

> This is the release dashboard:
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>
> *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a
> blocker for 0.29.0/1.0 release, please unset the fix version.
>
> On Thu, May 26, 2016 at 3:44 PM, Vinod Kone  wrote:
>
>> Thanks for asking the questions Zameer. Wanted to give some clarification
>> regarding the thought process for releasing 1.0.
>>
>> The reason for cutting  a 1.0, is because we want to signal that the
>> Mesos project has reached a level of maturity to the wider community. Among
>> other things we are confident at this point that the *foundations* we laid
>> for the new APIs are mature and could be evolved in a backwards compatible
>> way. We laid the foundations almost an year ago (at last MesosCon) and
>> since then have been busy implementing the backend to drive the API.  Even
>> the newly released design doc for the operator API is built on the same
>> foundations as the scheduler/executor APIs. While we have been tweaking the
>> API backend for a while now the API definitions have mostly stayed the
>> same. Part of the reason it took this long is because we really wanted to
>> be sure the basic building blocks were solid.
>>
>> MesosCon is a great opportunity for us to drum up excitement about the
>> new APIs and invite them to start using/testing it. Like any other OSS
>> project, as people and organizations start using the new APIs in staging
>> and production, we will make stability and implementation improvements. The
>> long period for the RC will also help catching issues with API foundations
>> themselves. We have had a bit of chicken and egg problem having people
>> consume the new APIs because most don't want to use it in production unless
>> it is declared production ready and we can't call it production ready until
>> someone uses them in production.
>>
>> Having said all that stability and production readiness is paramount for
>> the project.  That is never going to change. In the case of the new APIs,
>> we have developed C++ frameworks using the new APIs and having been running
>> them as part of ASF CI for months now. Mesosphere, for example, also has an
>> internal cluster where frameworks using these new APIs have been baking for
>> a while and had done (and doing) rigorous tests (network partitions,
>> scaling tests, functional tests). Community members from IBM have also been
>> instrumental in testing the new APIs. We are hoping after 1.0 more people
>> would be willing and excited to consume these new APIs and stress test in
>> their environments.
>>
>> At the end of the day, while new APIs are an important part of Mesos 1.0
>> it's not the only reason for cutting a 1.0 release. Mesos has a slew of
>> exciting features and a thriving eco system and we would love to have more
>> people excited and get a taste of it. 1.0 is just a start...
>>
>> Hope that helps,
>>
>>
>> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:
>>
>>> 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
>>>