+1 sounds good to me. However, if we end up going with (2), I'd commit to test the new RC and provide a +1 tonight.
On Tue, Jul 26, 2016 at 10:02 PM, Jie Yu <yujie....@gmail.com> wrote: > I prefer 2 if possible. Since this is a UI fix which should be easy to > validate. I am worried about people trying 1.0.0 because of the blog posts > without noticing 1.0.1. If 2 does not work, I am OK with 1. > > > On Jul 26, 2016, at 5:39 PM, Vinod Kone <vinodk...@apache.org> 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 <xuj...@apple.com> 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 <yujie....@gmail.com> 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 <xuj...@apple.com> 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 <ka...@mesosphere.io> wrote: >> >> +1 (binding) >> >> OpenSUSE Tumbleweed: >> ./configure --disable-java --disable-python && make check >> >> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zhitaoli...@gmail.com> 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 <bmah...@apache.org> >> 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 <g...@mesosphere.io> 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 <haosd...@gmail.com> 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 <ka...@mesosphere.io> >> >> 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 <vinodk...@apache.org> >> >> 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 >> >> >> >> >> >> >
