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
