+1 Tested on CentOS 7.
- sudo make check - upgrade from 0.28.2 to 1.0.0-rc2 On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <a...@mesosphere.com> wrote: > Haosdent investigated the issue, and it seems that health checks do work > for docker executor. Hence I retract my negative vote. > > On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <a...@mesosphere.com> > wrote: > >> -1 (binding): MESOS-5848 >> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the >> way. >> >> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zhitaoli...@gmail.com> wrote: >> >>> +1 (nonbinding) >>> >>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and >>> downgrade on a small test cluster for both master and slave. >>> >>> >>> >>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> >>> wrote: >>> >>>> None of the stable builds have SSL yet. The first SSL-enabled stable >>>> build >>>> will be 1.0.0. Sorry for the confusion. >>>> >>>> Kapil >>>> >>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zhitaoli...@gmail.com> >>>> wrote: >>>> >>>> > Hi Kapil, >>>> > >>>> > Do you mean that the stable builds from >>>> > http://open.mesosphere.com/downloads/mesos is using the new >>>> configuration? >>>> > >>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> >>>> wrote: >>>> > >>>> >> The binary rpm/deb packages can be found here: >>>> >> >>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2 >>>> >> . >>>> >> >>>> >> Please note that starting with the 1.0.0 release (including RCs and >>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty >>>> >> module dependency installation. Here is the configure command line: >>>> >> ./configure --enable-libevent --enable-ssl >>>> >> --enable-install-module-dependencies >>>> >> >>>> >> As always, the stable builds are available at: >>>> >> http://open.mesosphere.com/downloads/mesos >>>> >> >>>> >> The instructions for nightly builds are available at: >>>> >> http://open.mesosphere.com/downloads/mesos-nightly/ >>>> >> >>>> >> Best, >>>> >> Kapil >>>> >> >>>> >> >>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vinodk...@apache.org> >>>> wrote: >>>> >> > >>>> >> > Hi all, >>>> >> > >>>> >> > >>>> >> > Please vote on releasing the following candidate as Apache Mesos >>>> 1.0.0. >>>> >> > >>>> >> > >>>> >> > 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 >>>> >> > >>>> >> > 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 >>>> >> > >>>> >> > >>>> >> > 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-rc2 >>>> >> > >>>> >> > >>>> >> >>>> -------------------------------------------------------------------------------- >>>> >> > >>>> >> > >>>> >> > The candidate for Mesos 1.0.0 release is available at: >>>> >> > >>>> >> > >>>> >> >>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz >>>> >> > >>>> >> > >>>> >> > The tag to be voted on is 1.0.0-rc2: >>>> >> > >>>> >> > >>>> >> >>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2 >>>> >> > >>>> >> > >>>> >> > The MD5 checksum of the tarball can be found at: >>>> >> > >>>> >> > >>>> >> >>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/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-rc2/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-1149 >>>> >> > >>>> >> > >>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0! >>>> >> > >>>> >> > >>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a >>>> >> > majority of at least 3 +1 PMC votes are cast. >>>> >> > >>>> >> > >>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0 >>>> >> > >>>> >> > [ ] -1 Do not release this package because ... >>>> >> > >>>> >> > >>>> >> > Thanks, >>>> >> > >>>> >> > Vinod >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Cheers, >>>> > >>>> > Zhitao Li >>>> > >>>> >>> >>> >>> >>> -- >>> Cheers, >>> >>> Zhitao Li >>> >> >> > -- Best Regards, Haosdent Huang
