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 >> > >
