Thanks Yan. I will release 1.0 and call out the known issues. We will start the prep for a 1.0.1 later this week.
On Tue, Jul 26, 2016 at 7:32 PM, Yan Xu <[email protected]> wrote: > I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or > 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call > out the known issue. > > > On Jul 26, 2016, at 7:09 PM, Adam Bordelon <[email protected]> wrote: > > > > I don't like the idea of 2) bypassing the 72 hour voting period, so I'd > > suggest either we: > > 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it, > > then cut 1.0.1 soon after with this and other fixes. > > 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather > than > > an official release. After 72hrs we can hopefully call rc5 the official > 1.0 > > (or maybe more blockers come up). We could have more blogs/press then > about > > the official 1.0 release. > > 1c) push the press releases and announcements out a few more days. Not > sure > > if this is possible at this point? > > I'd prefer 1c) if possible, or a/b otherwise. > > > > On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman < > > [email protected]> wrote: > > > >> I agree with Vinod that we should go with option 1. I think redirect is > a > >> valuable feature but it's not imperative for the operation of the > cluster. > >> > >> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <[email protected]> > wrote: > >> > >>> We've the ASF press wire and other community blog posts lined up to be > >>> posted tomorrow, so it will be really hard to tell all those folks to > >>> postpone it this late. I've a couple options that I want to propose > >>> > >>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this > >>> bug. > >>> > >>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in > >>> tonight without doing the typical 72 hour voting period. > >>> > >>> > >>> I'm personally leaning towards 1) given the timing and the nature of > the > >>> bug. What do others think? PMC? > >>> > >>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <[email protected]> wrote: > >>> > >>>> I don't mind if it's shepherd by folks with more front-end expertise. > >>>> Actually my original suggested solution on > >>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. > >>>> Let's discuss the actual fix on the ticket, I feel that a short term > fix > >>>> shouldn't be more than a few lines to unblock the release. > >>>> > >>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <[email protected]> wrote: > >>>> > >>>> Yan, are you going to shepherd the fix for this one? If yes, when do > you > >>>> think it can be done? > >>>> > >>>> - Jie > >>>> > >>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <[email protected]> wrote: > >>>> > >>>> -1 > >>>> > >>>> We tested it in our testing environment but webUI redirect didn't > work. > >>>> We > >>>> filed: https://issues.apache.org/jira/browse/MESOS-5911 > >>>> > >>>> Given that webUI is the portal for Mesos clusters I feel that we > should > >>>> at > >>>> least have a basic fix (more context in the JIRA) before release 1.0. > >>>> Thoughts? > >>>> > >>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <[email protected]> wrote: > >>>> > >>>> +1 (binding) > >>>> > >>>> OpenSUSE Tumbleweed: > >>>> ./configure --disable-java --disable-python && make check > >>>> > >>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <[email protected]> > >>>> wrote: > >>>> > >>>> Also tested: > >>>> > >>>> make check passes on OS X > >>>> > >>>> One thing I found when testing RC4 debian with Aurora integration test > >>>> suite (on its master) is that scheduler previously expected GPU > resource > >>>> will not receive offers without new `GPU_RESOURCES` capability even > it's > >>>> the only scheduler. > >>>> > >>>> Given that GPU support is not technically released until 1.0, I don't > >>>> consider this is a blocker to me, but it might be surprising to people > >>>> already testing GPU support. > >>>> > >>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <[email protected] > > > >>>> wrote: > >>>> > >>>> +1 (binding) > >>>> > >>>> OS X 10.11.6 > >>>> ./configure --disable-python --disable-java > >>>> make check > >>>> > >>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <[email protected]> > wrote: > >>>> > >>>> +1 (non-binding) > >>>> > >>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one > >>>> > >>>> test > >>>> > >>>> failure: ExamplesTest.PythonFramework fails for me the first time it's > >>>> executed as part of the whole test suite, and then succeeds on > >>>> > >>>> subsequent > >>>> > >>>> executions. I'm investigating further, and will file a ticket if > >>>> > >>>> necessary. > >>>> > >>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4 > >>>> > >>>> Cheers, > >>>> Greg > >>>> > >>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <[email protected]> wrote: > >>>> > >>>> +1 > >>>> > >>>> * make check in CentOS 7.2 > >>>> * make check in Ubuntu 14.04 > >>>> * test upgrade from 0.28.2 to 1.0.0-rc4 > >>>> > >>>> > >>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <[email protected]> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> One can find the deb/rpm packages here: > >>>> > >>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4 > >>>> > >>>> > >>>> And here are the corresponding docker images based off of Ubuntu > >>>> > >>>> 14.04: > >>>> > >>>> mesosphere/mesos:1.0.0-rc4 > >>>> mesosphere/mesos-master:1.0.0-rc4 > >>>> mesosphere/mesos-slave:1.0.0-rc4 > >>>> > >>>> Kapil > >>>> > >>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <[email protected]> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> Please vote on releasing the following candidate as Apache Mesos > >>>> > >>>> 1.0.0. > >>>> > >>>> > >>>> *The vote is open until Tue Jul 25 11:00:00 PDT 2016 and passes > >>>> > >>>> if a > >>>> > >>>> majority of at least 3 +1 PMC votes are cast.* > >>>> > >>>> 1.0.0 includes the following: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > -------------------------------------------------------------------------------- > >>>> > >>>> > >>>> * Scheduler and Executor v1 HTTP APIs are now considered stable. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4791] - **Experimental** support for v1 Master and > >>>> > >>>> Agent > >>>> > >>>> APIs. > >>>> > >>>> These > >>>> > >>>> APIs let operators and services (monitoring, load balancers) > >>>> > >>>> send > >>>> > >>>> HTTP > >>>> > >>>> requests to '/api/v1' endpoint on master or agent. See > >>>> > >>>> > >>>> `docs/operator-http-api.md` for details. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4828] - **Experimental** support for a new `disk/xfs' > >>>> > >>>> isolator > >>>> > >>>> > >>>> > >>>> has been added to isolate disk resources more efficiently. > >>>> > >>>> Please > >>>> > >>>> refer to > >>>> > >>>> docs/mesos-containerizer.md for more details. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4355] - **Experimental** support for Docker volume > >>>> > >>>> plugin. > >>>> > >>>> We > >>>> > >>>> added a > >>>> > >>>> new isolator 'docker/volume' which allows users to use > >>>> > >>>> external > >>>> > >>>> volumes in > >>>> > >>>> Mesos containerizer. Currently, the isolator interacts with > >>>> > >>>> the > >>>> > >>>> Docker > >>>> > >>>> volume plugins using a tool called 'dvdcli'. By speaking the > >>>> > >>>> Docker > >>>> > >>>> volume > >>>> > >>>> plugin API, most of the Docker volume plugins are supported. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4641] - **Experimental** A new network isolator, the > >>>> > >>>> > >>>> `network/cni` isolator, has been introduced in the > >>>> `MesosContainerizer`. The > >>>> > >>>> `network/cni` isolator implements the Container Network > >>>> > >>>> Interface > >>>> > >>>> (CNI) > >>>> > >>>> specification proposed by CoreOS. With CNI the `network/cni` > >>>> > >>>> isolator > >>>> > >>>> is > >>>> > >>>> able to allocate a network namespace to Mesos containers and > >>>> > >>>> attach > >>>> > >>>> the > >>>> > >>>> container to different types of IP networks by invoking > >>>> > >>>> network > >>>> > >>>> drivers > >>>> > >>>> called CNI plugins. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-2948, MESOS-5403] - The authorizer interface has been > >>>> refactored in > >>>> > >>>> order to decouple the ACLs definition language from the > >>>> > >>>> interface. > >>>> > >>>> > >>>> > >>>> It additionally includes the option of retrieving > >>>> > >>>> `ObjectApprover`. > >>>> > >>>> An > >>>> > >>>> `ObjectApprover` can be used to synchronously check > >>>> > >>>> authorizations > >>>> > >>>> for > >>>> > >>>> a > >>>> > >>>> given object and is hence useful when authorizing a large > >>>> > >>>> number > >>>> > >>>> of > >>>> > >>>> objects > >>>> > >>>> and/or large objects (which need to be copied using request > >>>> > >>>> based > >>>> > >>>> > >>>> > >>>> authorization). NOTE: This is a **breaking change** for > >>>> > >>>> authorizer > >>>> > >>>> modules. > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-5405] - The `subject` and `object` fields in > >>>> authorization::Request > >>>> > >>>> have been changed from required to optional. If either of > >>>> > >>>> these > >>>> > >>>> fields > >>>> > >>>> is > >>>> > >>>> not set, the request should only be authorized if any > >>>> > >>>> subject/object > >>>> > >>>> should > >>>> > >>>> be allowed. > >>>> > >>>> > >>>> NOTE: This is a semantic change for authorizer modules. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based > >>>> > >>>> HTTP > >>>> > >>>> endpoint > >>>> > >>>> filtering enables operators to restrict what part of the > >>>> > >>>> cluster > >>>> > >>>> state > >>>> > >>>> a > >>>> > >>>> user is authorized to see. > >>>> > >>>> > >>>> Consider for example the `/state` master endpoint: an > >>>> > >>>> operator can > >>>> > >>>> now > >>>> > >>>> authorize users to only see a subset of the running > >>>> > >>>> frameworks, > >>>> > >>>> tasks, > >>>> > >>>> or > >>>> > >>>> Consider for example the `/state` master endpoint: an > >>>> > >>>> operator can > >>>> > >>>> now > >>>> > >>>> authorize users to only see a subset of the running > >>>> > >>>> frameworks, > >>>> > >>>> tasks, > >>>> > >>>> or > >>>> > >>>> executors. The following endpoints support HTTP endpoint > >>>> > >>>> filtering: > >>>> > >>>> > >>>> > >>>> '/state', '/state-summary', '/tasks', > >>>> > >>>> '/frameworks','/weights', > >>>> > >>>> > >>>> > >>>> and '/roles'. Additonally the following v1 API calls support > >>>> filtering: > >>>> > >>>> 'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and > >>>> 'GET_TASKS'. > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4909] - Tasks can now specify a kill policy. They are > >>>> best-effort, > >>>> > >>>> because machine failures or forcible terminations may occur. > >>>> Currently, the > >>>> > >>>> only available kill policy is how long to wait between > >>>> > >>>> graceful > >>>> > >>>> and > >>>> > >>>> forcible > >>>> > >>>> task kill. In the future, more policies may be available (e.g. > >>>> > >>>> hitting > >>>> > >>>> an > >>>> > >>>> HTTP endpoint, running a command, etc). Note that it is the > >>>> executor's > >>>> > >>>> responsibility to enforce kill policies. For executor-less > >>>> command-based > >>>> > >>>> tasks, the kill is performed via sending a signal to the task > >>>> process: > >>>> > >>>> SIGTERM for the graceful kill and SIGKILL for the forcible > >>>> > >>>> kill. > >>>> > >>>> For > >>>> > >>>> docker > >>>> > >>>> executor-less tasks the grace period is passed to 'docker stop > >>>> --time'. This > >>>> > >>>> feature supersedes the '--docker_stop_timeout', which is now > >>>> deprecated. > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4908] - The task kill policy defined within 'TaskInfo' > >>>> > >>>> can > >>>> > >>>> now > >>>> > >>>> be > >>>> > >>>> overridden when the scheduler kills the task. This can be > >>>> > >>>> used by > >>>> > >>>> schedulers > >>>> > >>>> to forcefully kill a task which is already being killed, e.g. > >>>> > >>>> if > >>>> > >>>> something > >>>> > >>>> went wrong during a graceful kill and a forcible kill is > >>>> > >>>> desired. > >>>> > >>>> Note > >>>> > >>>> that > >>>> > >>>> it is the executor's responsibility to honor the > >>>> 'Event.kill.kill_policy' > >>>> > >>>> field and override the task's kill policy and kill policy > >>>> > >>>> from a > >>>> > >>>> previous > >>>> > >>>> kill task request. To use this feature, schedulers and > >>>> > >>>> executors > >>>> > >>>> must > >>>> > >>>> > >>>> > >>>> support HTTP API; use the '--http_command_executor' agent > >>>> > >>>> flag to > >>>> > >>>> ensure > >>>> > >>>> the agent launches the HTTP API based command executor. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4949] - The executor shutdown grace period can now be > >>>> configured in > >>>> > >>>> `ExecutorInfo`, which overrides the agent flag. When shutting > >>>> > >>>> down an > >>>> > >>>> > >>>> > >>>> executor the agent will wait in a best-effort manner for the > >>>> > >>>> grace > >>>> > >>>> period > >>>> > >>>> specified here before forcibly destroying the container. The > >>>> > >>>> executor > >>>> > >>>> must > >>>> > >>>> not assume that it will always be allotted the full grace > >>>> > >>>> period, > >>>> > >>>> as > >>>> > >>>> the > >>>> > >>>> agent may decide to allot a shorter period and failures / > >>>> > >>>> forcible > >>>> > >>>> > >>>> > >>>> terminations may occur. Together with kill policies this gives > >>>> frameworks > >>>> > >>>> flexibility around how to clean up tasks and executors. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-3094] - **Experimental** support for launching mesos > >>>> > >>>> tasks > >>>> > >>>> on > >>>> > >>>> > >>>> > >>>> Windows. Note that there are no isolation guarantees provided > >>>> > >>>> yet. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4090] - The `mesos.native` python module has been split > >>>> > >>>> into > >>>> > >>>> two, > >>>> > >>>> `mesos.executor` and `mesos.scheduler`. This change also > >>>> > >>>> removes > >>>> > >>>> > >>>> > >>>> un-necessary 3rd party dependencies from `mesos.executor` and > >>>> > >>>> > >>>> `mesos.scheduler`. `mesos.native` still exists, combining both > >>>> > >>>> modules > >>>> > >>>> for > >>>> > >>>> backwards compatibility with existing code. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-1478] - Phase I of the Slave to Agent rename is > >>>> > >>>> complete. > >>>> > >>>> To > >>>> > >>>> support > >>>> > >>>> the rename, new duplicate flags (e.g., > >>>> > >>>> --agent_reregister_timeout), > >>>> > >>>> new > >>>> > >>>> * [MESOS-1478] - Phase I of the Slave to Agent rename is > >>>> > >>>> complete. > >>>> > >>>> To > >>>> > >>>> support > >>>> > >>>> the rename, new duplicate flags (e.g., > >>>> > >>>> --agent_reregister_timeout), > >>>> > >>>> new > >>>> > >>>> binaries (e.g., mesos-agent) and WebUI sandbox links have been > >>>> > >>>> added. > >>>> > >>>> All > >>>> > >>>> the logging output has been updated to use the term 'agent' > >>>> > >>>> now. > >>>> > >>>> Flags, > >>>> > >>>> binaries and scripts with 'slave' keyword have been deprecated > >>>> > >>>> (see > >>>> > >>>> > >>>> > >>>> "Deprecations section below"). > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4312] - **Experimental** support for building and > >>>> > >>>> running > >>>> > >>>> mesos > >>>> > >>>> on > >>>> > >>>> IBM PowerPC platform. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4189] - Weights for resource roles can now be > >>>> > >>>> configured > >>>> > >>>> dynamically > >>>> > >>>> via the new '/weights' endpoint on the master. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> * [MESOS-4424] - Support for using Nvidia GPUs as a resource in > >>>> > >>>> the > >>>> > >>>> > >>>> > >>>> Mesos "unified" containerizer. This support includes running > >>>> containers > >>>> > >>>> with and without filesystem isolation (i.e. running both > >>>> > >>>> imageless > >>>> > >>>> > >>>> > >>>> containers as well as containers using a docker image). > >>>> > >>>> Frameworks > >>>> > >>>> must > >>>> > >>>> opt-in to receiving GPU resources via the GPU_RESOURCES > >>>> > >>>> framework > >>>> > >>>> > >>>> > >>>> capability (see the scarce resource problem in MESOS-5377). We > >>>> support > >>>> > >>>> 'nvidia-docker'-style docker containers by injecting a volume > >>>> > >>>> that > >>>> > >>>> > >>>> > >>>> contains the Nvidia libraries / binaries when the docker > >>>> > >>>> image has > >>>> > >>>> > >>>> > >>>> the 'com.nvidia.volumes.needed' label. Support for the docker > >>>> > >>>> > >>>> containerizer will come in a future release. > >>>> > >>>> > >>>> > >>>> * [MESOS-5724] - SSL certificate validation allows for > >>>> > >>>> additional IP > >>>> > >>>> address > >>>> > >>>> subject alternative name extension verification. > >>>> > >>>> 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=1.0.0-rc4 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > -------------------------------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> The candidate for Mesos 1.0.0 release is available at: > >>>> > >>>> > >>>> > >>>> > >>>> > https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc4/mesos-1.0.0.tar.gz > >>>> > >>>> > >>>> > >>>> The tag to be voted on is 1.0.0-rc4: > >>>> > >>>> > >>>> > >>>> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc4 > >>>> > >>>> > >>>> > >>>> The MD5 checksum of the tarball can be found at: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc4/mesos-1.0.0.tar.gz.md5 > >>>> > >>>> > >>>> > >>>> The signature of the tarball can be found at: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc4/mesos-1.0.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-1153 > >>>> > >>>> > >>>> > >>>> Please vote on releasing this package as Apache Mesos 1.0.0! > >>>> > >>>> > >>>> [ ] +1 Release this package as Apache Mesos 1.0.0 > >>>> > >>>> [ ] -1 Do not release this package because ... > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best Regards, > >>>> Haosdent Huang > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Cheers, > >>>> > >>>> Zhitao Li > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >
