Looks like we missed a cherry pick. I'm cancelling this vote and spinning up rc4.
On Fri, Jul 22, 2016 at 2:24 PM, 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-rc3 > > > -------------------------------------------------------------------------------- > > > The candidate for Mesos 1.0.0 release is available at: > > https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc3/mesos-1.0.0.tar.gz > > > The tag to be voted on is 1.0.0-rc3: > > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc3 > > > The MD5 checksum of the tarball can be found at: > > > https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc3/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-rc3/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-1151 > > > 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, >
