mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Bordelon <a...@mesosphere.io>
Subject Re: 1.0 Release Candidate
Date Sun, 29 May 2016 09:31:47 GMT
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 <vinodkone@apache.org> 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 <vinodkone@apache.org> 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 <zmanji@apache.org> 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 <vinodkone@apache.org>
>>> 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 <
>>> > jeffschroeder@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 <vinodkone@apache.org>
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 <https://issues.apache.org/jira/browse/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
>>> >>> <
>>> https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2&pli=1#
>>> >
>>> >>> .
>>> >>>
>>> >>> 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
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Mime
View raw message