mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <>
Subject [VOTE] Release Apache Mesos 1.0.0 (rc2)
Date Fri, 08 Jul 2016 01:35:41 GMT
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.

    APIs let operators and services (monitoring, load balancers) send HTTP

    requests to '/api/v1' endpoint on master or agent. See

    `docs/` for details.

  * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator

    has been added to isolate disk resources more efficiently. Please refer

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

    Mesos containerizer. Currently, the isolator interacts with the Docker

    volume plugins using a tool called 'dvdcli'. By speaking the Docker

    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

    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

    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

    given object and is hence useful when authorizing a large number of

    and/or large objects (which need to be copied using request based

    authorization). NOTE: This is a **breaking change** for authorizer

  * [MESOS-5405] - The `subject` and `object` fields in

    have been changed from required to optional. If either of these fields

    not set, the request should only be authorized if any subject/object

    be allowed.

    NOTE: This is a semantic change for authorizer modules.

  * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP

    filtering enables operators to restrict what part of the cluster state

    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,

    executors. The following endpoints support HTTP endpoint filtering:

    '/state', '/state-summary', '/tasks', '/frameworks','/weights',

    and '/roles'. Additonally the following v1 API calls support filtering:


  * [MESOS-4909] - Tasks can now specify a kill policy. They are

    because machine failures or forcible terminations may occur. Currently,

    only available kill policy is how long to wait between graceful and

    task kill. In the future, more policies may be available (e.g. hitting

    HTTP endpoint, running a command, etc). Note that it is the executor's

    responsibility to enforce kill policies. For executor-less

    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

    executor-less tasks the grace period is passed to 'docker stop --time'.

    feature supersedes the '--docker_stop_timeout', which is now

  * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now

    overridden when the scheduler kills the task. This can be used by

    to forcefully kill a task which is already being killed, e.g. if

    went wrong during a graceful kill and a forcible kill is desired. Note

    it is the executor's responsibility to honor the

    field and override the task's kill policy and kill policy from a

    kill task request. To use this feature, schedulers and executors must

    support HTTP API; use the '--http_command_executor' agent flag to

    the agent launches the HTTP API based command executor.

  * [MESOS-4949] - The executor shutdown grace period can now be configured

    `ExecutorInfo`, which overrides the agent flag. When shutting down an

    executor the agent will wait in a best-effort manner for the grace

    specified here before forcibly destroying the container. The executor

    not assume that it will always be allotted the full grace period, as

    agent may decide to allot a shorter period and failures / forcible

    terminations may occur. Together with kill policies this gives

    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

    `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

    backwards compatibility with existing code.

  * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To

    the rename, new duplicate flags (e.g., --agent_reregister_timeout), new

    binaries (e.g., mesos-agent) and WebUI sandbox links have been added.

    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

    IBM PowerPC platform.

  * [MESOS-4189] - Weights for resource roles can now be configured

    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

    subject alternative name extension verification.

The CHANGELOG for the release is available at:;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2


The candidate for Mesos 1.0.0 release is available at:

The tag to be voted on is 1.0.0-rc2:;a=commit;h=1.0.0-rc2

The MD5 checksum of the tarball can be found at:

The signature of the tarball can be found at:

The PGP key used to sign the release is here:

The JAR is up in Maven in a staging repository here:

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



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message