You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Vinod Kone <vi...@apache.org> on 2016/07/27 14:39:02 UTC
[RESULT][VOTE] Release Apache Mesos 1.0.0 (rc4)
Hi all,
The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
+1 (Binding)
------------------------------
Kapil Arya
Jie Yu
Benjamin Mahler
+1 (Non-binding)
------------------------------
Haosdent
Greg Mann
Zhitao Li
+0
-----
Yan Xu
There were no -1 votes.
*NOTE: There were a couple known issues [MESOS-5911
<https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
<https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
in time for the 1.0. We plan to do a patch release to fix these ASAP.*
Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/1.0.0
It is recommended to use a mirror to download the release:
http://www.apache.org/dyn/closer.cgi
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
The mesos-1.0.0.jar has been released to:
https://repository.apache.org
The website (http://mesos.apache.org) will be updated shortly to reflect
this release.
Thanks,
On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>
Re: [RESULT][VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@gmail.com>.
The 1.0 blog post is up: http://mesos.apache.org/blog/mesos-1-0-0-released/
Thank you all for making this possible!
@vinodkone
> On Jul 27, 2016, at 7:39 AM, Vinod Kone <vi...@apache.org> wrote:
>
> Hi all,
>
> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>
>
>
> +1 (Binding)
>
> ------------------------------
>
> Kapil Arya
>
> Jie Yu
>
> Benjamin Mahler
>
>
>
> +1 (Non-binding)
>
> ------------------------------
>
> Haosdent
>
> Greg Mann
>
> Zhitao Li
>
>
>
> +0
>
> -----
>
> Yan Xu
>
>
>
> There were no -1 votes.
>
>
>
> NOTE: There were a couple known issues [MESOS-5911, MESOS-5913] that couldn't be fixed in time for the 1.0. We plan to do a patch release to fix these ASAP.
>
>
>
> Please find the release at:
>
> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>
>
>
> It is recommended to use a mirror to download the release:
>
> http://www.apache.org/dyn/closer.cgi
>
>
>
> 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
>
>
>
> The mesos-1.0.0.jar has been released to:
>
> https://repository.apache.org
>
>
>
> The website (http://mesos.apache.org) will be updated shortly to reflect this release.
>
>
>
> Thanks,
>
>
>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>
>
Re: [RESULT][VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@gmail.com>.
The 1.0 blog post is up: http://mesos.apache.org/blog/mesos-1-0-0-released/
Thank you all for making this possible!
@vinodkone
> On Jul 27, 2016, at 7:39 AM, Vinod Kone <vi...@apache.org> wrote:
>
> Hi all,
>
> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>
>
>
> +1 (Binding)
>
> ------------------------------
>
> Kapil Arya
>
> Jie Yu
>
> Benjamin Mahler
>
>
>
> +1 (Non-binding)
>
> ------------------------------
>
> Haosdent
>
> Greg Mann
>
> Zhitao Li
>
>
>
> +0
>
> -----
>
> Yan Xu
>
>
>
> There were no -1 votes.
>
>
>
> NOTE: There were a couple known issues [MESOS-5911, MESOS-5913] that couldn't be fixed in time for the 1.0. We plan to do a patch release to fix these ASAP.
>
>
>
> Please find the release at:
>
> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>
>
>
> It is recommended to use a mirror to download the release:
>
> http://www.apache.org/dyn/closer.cgi
>
>
>
> 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
>
>
>
> The mesos-1.0.0.jar has been released to:
>
> https://repository.apache.org
>
>
>
> The website (http://mesos.apache.org) will be updated shortly to reflect this release.
>
>
>
> Thanks,
>
>
>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
Oh, it is because Homebrew still using Mesos 0.28.1. Open a pull request to
update it to Mesos 1.0.0 just now.
https://github.com/Homebrew/homebrew-core/pull/3704 Sorry for noise.
On Mon, Aug 8, 2016 at 6:15 PM, haosdent <ha...@gmail.com> wrote:
> Hi, I noted that we have not yet update mesos python packages in pip
>
> ```
> pip show mesos
> ---
> Metadata-Version: 1.0
> Name: mesos
> Version: 0.28.1
> Summary: Python bindings for mesos
> Home-page: http://pypi.python.org/pypi/mesos
> Author: Apache Mesos
> Author-email: mesos@apache.com
> License: Apache 2.0
> Location: /usr/local/lib/python2.7/site-packages
> Requires: mesos.interface, mesos.native
> Classifiers:
> ```
>
> On Fri, Jul 29, 2016 at 5:47 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> PS: Please note that starting with this Mesos 1.0.0 release, the binary
>> rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
>> (for the Mesosphere package repos hosted at: repo.mesosphere.com) are
>> built with libevent+SSL and module dependency installation (i.e.
>> `./configure --enable-libevent --enable-ssl --enable-install-module-
>> dependencies`).
>>
>> All future 1.x.y releases will continue to be configured with SSL+libevent
>>
>> All older releases, i.e., 0.x.y, will continue to be configured _without_
>> SSL+libevent.
>>
>> Best,
>> Kapil
>>
>>
>> On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>>> You can find the 1.0.0 rpm/deb packages at:
>>>
>>> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>>>
>>>
>>> And here are the corresponding docker images based off of Ubuntu 14.04:
>>>
>>> mesosphere/mesos:1.0.0
>>> mesosphere/mesos-master:1.0.0
>>> mesosphere/mesos-slave:1.0.0
>>>
>>> Kapil
>>>
>>> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
>>> jeffschroeder@computer.org> wrote:
>>>
>>>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>>>> header in the release post please?
>>>>
>>>> Great work otherwise everyone!
>>>>
>>>>
>>>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>>>
>>>>>
>>>>> +1 (Binding)
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Kapil Arya
>>>>>
>>>>> Jie Yu
>>>>>
>>>>> Benjamin Mahler
>>>>>
>>>>>
>>>>> +1 (Non-binding)
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Haosdent
>>>>>
>>>>> Greg Mann
>>>>>
>>>>> Zhitao Li
>>>>>
>>>>>
>>>>> +0
>>>>>
>>>>> -----
>>>>>
>>>>> Yan Xu
>>>>>
>>>>>
>>>>> There were no -1 votes.
>>>>>
>>>>>
>>>>> *NOTE: There were a couple known issues [MESOS-5911
>>>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>>>
>>>>>
>>>>> Please find the release at:
>>>>>
>>>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>>>
>>>>>
>>>>> It is recommended to use a mirror to download the release:
>>>>>
>>>>> http://www.apache.org/dyn/closer.cgi
>>>>>
>>>>>
>>>>> The CHANGELOG for the release is available at:
>>>>>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>>>>> lain;f=CHANGELOG;hb=1.0.0
>>>>>
>>>>>
>>>>> The mesos-1.0.0.jar has been released to:
>>>>>
>>>>> https://repository.apache.org
>>>>>
>>>>>
>>>>> The website (http://mesos.apache.org) will be updated shortly to
>>>>> reflect this release.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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_p
>>>>>> lain;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/orgapache
>>>>>> mesos-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,
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Text by Jeff, typos by iPhone
>>>>
>>>
>>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
Oh, it is because Homebrew still using Mesos 0.28.1. Open a pull request to
update it to Mesos 1.0.0 just now.
https://github.com/Homebrew/homebrew-core/pull/3704 Sorry for noise.
On Mon, Aug 8, 2016 at 6:15 PM, haosdent <ha...@gmail.com> wrote:
> Hi, I noted that we have not yet update mesos python packages in pip
>
> ```
> pip show mesos
> ---
> Metadata-Version: 1.0
> Name: mesos
> Version: 0.28.1
> Summary: Python bindings for mesos
> Home-page: http://pypi.python.org/pypi/mesos
> Author: Apache Mesos
> Author-email: mesos@apache.com
> License: Apache 2.0
> Location: /usr/local/lib/python2.7/site-packages
> Requires: mesos.interface, mesos.native
> Classifiers:
> ```
>
> On Fri, Jul 29, 2016 at 5:47 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> PS: Please note that starting with this Mesos 1.0.0 release, the binary
>> rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
>> (for the Mesosphere package repos hosted at: repo.mesosphere.com) are
>> built with libevent+SSL and module dependency installation (i.e.
>> `./configure --enable-libevent --enable-ssl --enable-install-module-
>> dependencies`).
>>
>> All future 1.x.y releases will continue to be configured with SSL+libevent
>>
>> All older releases, i.e., 0.x.y, will continue to be configured _without_
>> SSL+libevent.
>>
>> Best,
>> Kapil
>>
>>
>> On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>>> You can find the 1.0.0 rpm/deb packages at:
>>>
>>> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>>>
>>>
>>> And here are the corresponding docker images based off of Ubuntu 14.04:
>>>
>>> mesosphere/mesos:1.0.0
>>> mesosphere/mesos-master:1.0.0
>>> mesosphere/mesos-slave:1.0.0
>>>
>>> Kapil
>>>
>>> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
>>> jeffschroeder@computer.org> wrote:
>>>
>>>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>>>> header in the release post please?
>>>>
>>>> Great work otherwise everyone!
>>>>
>>>>
>>>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>>>
>>>>>
>>>>> +1 (Binding)
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Kapil Arya
>>>>>
>>>>> Jie Yu
>>>>>
>>>>> Benjamin Mahler
>>>>>
>>>>>
>>>>> +1 (Non-binding)
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Haosdent
>>>>>
>>>>> Greg Mann
>>>>>
>>>>> Zhitao Li
>>>>>
>>>>>
>>>>> +0
>>>>>
>>>>> -----
>>>>>
>>>>> Yan Xu
>>>>>
>>>>>
>>>>> There were no -1 votes.
>>>>>
>>>>>
>>>>> *NOTE: There were a couple known issues [MESOS-5911
>>>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>>>
>>>>>
>>>>> Please find the release at:
>>>>>
>>>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>>>
>>>>>
>>>>> It is recommended to use a mirror to download the release:
>>>>>
>>>>> http://www.apache.org/dyn/closer.cgi
>>>>>
>>>>>
>>>>> The CHANGELOG for the release is available at:
>>>>>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>>>>> lain;f=CHANGELOG;hb=1.0.0
>>>>>
>>>>>
>>>>> The mesos-1.0.0.jar has been released to:
>>>>>
>>>>> https://repository.apache.org
>>>>>
>>>>>
>>>>> The website (http://mesos.apache.org) will be updated shortly to
>>>>> reflect this release.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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_p
>>>>>> lain;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/orgapache
>>>>>> mesos-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,
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Text by Jeff, typos by iPhone
>>>>
>>>
>>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
Hi, I noted that we have not yet update mesos python packages in pip
```
pip show mesos
---
Metadata-Version: 1.0
Name: mesos
Version: 0.28.1
Summary: Python bindings for mesos
Home-page: http://pypi.python.org/pypi/mesos
Author: Apache Mesos
Author-email: mesos@apache.com
License: Apache 2.0
Location: /usr/local/lib/python2.7/site-packages
Requires: mesos.interface, mesos.native
Classifiers:
```
On Fri, Jul 29, 2016 at 5:47 AM, Kapil Arya <ka...@mesosphere.io> wrote:
> PS: Please note that starting with this Mesos 1.0.0 release, the binary
> rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
> (for the Mesosphere package repos hosted at: repo.mesosphere.com) are
> built with libevent+SSL and module dependency installation (i.e.
> `./configure --enable-libevent --enable-ssl --enable-install-module-
> dependencies`).
>
> All future 1.x.y releases will continue to be configured with SSL+libevent
>
> All older releases, i.e., 0.x.y, will continue to be configured _without_
> SSL+libevent.
>
> Best,
> Kapil
>
>
> On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> You can find the 1.0.0 rpm/deb packages at:
>>
>> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>>
>>
>> And here are the corresponding docker images based off of Ubuntu 14.04:
>>
>> mesosphere/mesos:1.0.0
>> mesosphere/mesos-master:1.0.0
>> mesosphere/mesos-slave:1.0.0
>>
>> Kapil
>>
>> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
>> jeffschroeder@computer.org> wrote:
>>
>>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>>> header in the release post please?
>>>
>>> Great work otherwise everyone!
>>>
>>>
>>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>>
>>>>
>>>> +1 (Binding)
>>>>
>>>> ------------------------------
>>>>
>>>> Kapil Arya
>>>>
>>>> Jie Yu
>>>>
>>>> Benjamin Mahler
>>>>
>>>>
>>>> +1 (Non-binding)
>>>>
>>>> ------------------------------
>>>>
>>>> Haosdent
>>>>
>>>> Greg Mann
>>>>
>>>> Zhitao Li
>>>>
>>>>
>>>> +0
>>>>
>>>> -----
>>>>
>>>> Yan Xu
>>>>
>>>>
>>>> There were no -1 votes.
>>>>
>>>>
>>>> *NOTE: There were a couple known issues [MESOS-5911
>>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>>
>>>>
>>>> Please find the release at:
>>>>
>>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>>
>>>>
>>>> It is recommended to use a mirror to download the release:
>>>>
>>>> http://www.apache.org/dyn/closer.cgi
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> The mesos-1.0.0.jar has been released to:
>>>>
>>>> https://repository.apache.org
>>>>
>>>>
>>>> The website (http://mesos.apache.org) will be updated shortly to
>>>> reflect this release.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Text by Jeff, typos by iPhone
>>>
>>
>>
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
Hi, I noted that we have not yet update mesos python packages in pip
```
pip show mesos
---
Metadata-Version: 1.0
Name: mesos
Version: 0.28.1
Summary: Python bindings for mesos
Home-page: http://pypi.python.org/pypi/mesos
Author: Apache Mesos
Author-email: mesos@apache.com
License: Apache 2.0
Location: /usr/local/lib/python2.7/site-packages
Requires: mesos.interface, mesos.native
Classifiers:
```
On Fri, Jul 29, 2016 at 5:47 AM, Kapil Arya <ka...@mesosphere.io> wrote:
> PS: Please note that starting with this Mesos 1.0.0 release, the binary
> rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
> (for the Mesosphere package repos hosted at: repo.mesosphere.com) are
> built with libevent+SSL and module dependency installation (i.e.
> `./configure --enable-libevent --enable-ssl --enable-install-module-
> dependencies`).
>
> All future 1.x.y releases will continue to be configured with SSL+libevent
>
> All older releases, i.e., 0.x.y, will continue to be configured _without_
> SSL+libevent.
>
> Best,
> Kapil
>
>
> On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> You can find the 1.0.0 rpm/deb packages at:
>>
>> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>>
>>
>> And here are the corresponding docker images based off of Ubuntu 14.04:
>>
>> mesosphere/mesos:1.0.0
>> mesosphere/mesos-master:1.0.0
>> mesosphere/mesos-slave:1.0.0
>>
>> Kapil
>>
>> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
>> jeffschroeder@computer.org> wrote:
>>
>>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>>> header in the release post please?
>>>
>>> Great work otherwise everyone!
>>>
>>>
>>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>>
>>>>
>>>> +1 (Binding)
>>>>
>>>> ------------------------------
>>>>
>>>> Kapil Arya
>>>>
>>>> Jie Yu
>>>>
>>>> Benjamin Mahler
>>>>
>>>>
>>>> +1 (Non-binding)
>>>>
>>>> ------------------------------
>>>>
>>>> Haosdent
>>>>
>>>> Greg Mann
>>>>
>>>> Zhitao Li
>>>>
>>>>
>>>> +0
>>>>
>>>> -----
>>>>
>>>> Yan Xu
>>>>
>>>>
>>>> There were no -1 votes.
>>>>
>>>>
>>>> *NOTE: There were a couple known issues [MESOS-5911
>>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>>
>>>>
>>>> Please find the release at:
>>>>
>>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>>
>>>>
>>>> It is recommended to use a mirror to download the release:
>>>>
>>>> http://www.apache.org/dyn/closer.cgi
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> The mesos-1.0.0.jar has been released to:
>>>>
>>>> https://repository.apache.org
>>>>
>>>>
>>>> The website (http://mesos.apache.org) will be updated shortly to
>>>> reflect this release.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Text by Jeff, typos by iPhone
>>>
>>
>>
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
PS: Please note that starting with this Mesos 1.0.0 release, the binary
rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
(for the Mesosphere package repos hosted at: repo.mesosphere.com) are built
with libevent+SSL and module dependency installation (i.e.
`./configure --enable-libevent --enable-ssl --enable-install-module-
dependencies`).
All future 1.x.y releases will continue to be configured with SSL+libevent
All older releases, i.e., 0.x.y, will continue to be configured _without_
SSL+libevent.
Best,
Kapil
On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> You can find the 1.0.0 rpm/deb packages at:
>
> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>
>
> And here are the corresponding docker images based off of Ubuntu 14.04:
>
> mesosphere/mesos:1.0.0
> mesosphere/mesos-master:1.0.0
> mesosphere/mesos-slave:1.0.0
>
> Kapil
>
> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
> jeffschroeder@computer.org> wrote:
>
>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>> header in the release post please?
>>
>> Great work otherwise everyone!
>>
>>
>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>
>>>
>>> +1 (Binding)
>>>
>>> ------------------------------
>>>
>>> Kapil Arya
>>>
>>> Jie Yu
>>>
>>> Benjamin Mahler
>>>
>>>
>>> +1 (Non-binding)
>>>
>>> ------------------------------
>>>
>>> Haosdent
>>>
>>> Greg Mann
>>>
>>> Zhitao Li
>>>
>>>
>>> +0
>>>
>>> -----
>>>
>>> Yan Xu
>>>
>>>
>>> There were no -1 votes.
>>>
>>>
>>> *NOTE: There were a couple known issues [MESOS-5911
>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>
>>>
>>> Please find the release at:
>>>
>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>
>>>
>>> It is recommended to use a mirror to download the release:
>>>
>>> http://www.apache.org/dyn/closer.cgi
>>>
>>>
>>> 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
>>>
>>>
>>> The mesos-1.0.0.jar has been released to:
>>>
>>> https://repository.apache.org
>>>
>>>
>>> The website (http://mesos.apache.org) will be updated shortly to
>>> reflect this release.
>>>
>>>
>>> Thanks,
>>>
>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>>
>>>
>>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
PS: Please note that starting with this Mesos 1.0.0 release, the binary
rpm/deb packages published at http://open.mesosphere.com/downloads/mesos
(for the Mesosphere package repos hosted at: repo.mesosphere.com) are built
with libevent+SSL and module dependency installation (i.e.
`./configure --enable-libevent --enable-ssl --enable-install-module-
dependencies`).
All future 1.x.y releases will continue to be configured with SSL+libevent
All older releases, i.e., 0.x.y, will continue to be configured _without_
SSL+libevent.
Best,
Kapil
On Wed, Jul 27, 2016 at 6:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> You can find the 1.0.0 rpm/deb packages at:
>
> http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
>
>
> And here are the corresponding docker images based off of Ubuntu 14.04:
>
> mesosphere/mesos:1.0.0
> mesosphere/mesos-master:1.0.0
> mesosphere/mesos-slave:1.0.0
>
> Kapil
>
> On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <
> jeffschroeder@computer.org> wrote:
>
>> Small nit but can you s/experimnental/experimental/ under the "Storage"
>> header in the release post please?
>>
>> Great work otherwise everyone!
>>
>>
>> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>>
>>>
>>> +1 (Binding)
>>>
>>> ------------------------------
>>>
>>> Kapil Arya
>>>
>>> Jie Yu
>>>
>>> Benjamin Mahler
>>>
>>>
>>> +1 (Non-binding)
>>>
>>> ------------------------------
>>>
>>> Haosdent
>>>
>>> Greg Mann
>>>
>>> Zhitao Li
>>>
>>>
>>> +0
>>>
>>> -----
>>>
>>> Yan Xu
>>>
>>>
>>> There were no -1 votes.
>>>
>>>
>>> *NOTE: There were a couple known issues [MESOS-5911
>>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>>
>>>
>>> Please find the release at:
>>>
>>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>>
>>>
>>> It is recommended to use a mirror to download the release:
>>>
>>> http://www.apache.org/dyn/closer.cgi
>>>
>>>
>>> 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
>>>
>>>
>>> The mesos-1.0.0.jar has been released to:
>>>
>>> https://repository.apache.org
>>>
>>>
>>> The website (http://mesos.apache.org) will be updated shortly to
>>> reflect this release.
>>>
>>>
>>> Thanks,
>>>
>>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>>
>>>
>>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
You can find the 1.0.0 rpm/deb packages at:
http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0
mesosphere/mesos-master:1.0.0
mesosphere/mesos-slave:1.0.0
Kapil
On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <je...@computer.org>
wrote:
> Small nit but can you s/experimnental/experimental/ under the "Storage"
> header in the release post please?
>
> Great work otherwise everyone!
>
>
> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>
>> Hi all,
>>
>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>
>>
>> +1 (Binding)
>>
>> ------------------------------
>>
>> Kapil Arya
>>
>> Jie Yu
>>
>> Benjamin Mahler
>>
>>
>> +1 (Non-binding)
>>
>> ------------------------------
>>
>> Haosdent
>>
>> Greg Mann
>>
>> Zhitao Li
>>
>>
>> +0
>>
>> -----
>>
>> Yan Xu
>>
>>
>> There were no -1 votes.
>>
>>
>> *NOTE: There were a couple known issues [MESOS-5911
>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>
>>
>> Please find the release at:
>>
>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>
>>
>> It is recommended to use a mirror to download the release:
>>
>> http://www.apache.org/dyn/closer.cgi
>>
>>
>> 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
>>
>>
>> The mesos-1.0.0.jar has been released to:
>>
>> https://repository.apache.org
>>
>>
>> The website (http://mesos.apache.org) will be updated shortly to reflect
>> this release.
>>
>>
>> Thanks,
>>
>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>
>>
>>
>
> --
> Text by Jeff, typos by iPhone
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
You can find the 1.0.0 rpm/deb packages at:
http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0
mesosphere/mesos-master:1.0.0
mesosphere/mesos-slave:1.0.0
Kapil
On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <je...@computer.org>
wrote:
> Small nit but can you s/experimnental/experimental/ under the "Storage"
> header in the release post please?
>
> Great work otherwise everyone!
>
>
> On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
>
>> Hi all,
>>
>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>
>>
>> +1 (Binding)
>>
>> ------------------------------
>>
>> Kapil Arya
>>
>> Jie Yu
>>
>> Benjamin Mahler
>>
>>
>> +1 (Non-binding)
>>
>> ------------------------------
>>
>> Haosdent
>>
>> Greg Mann
>>
>> Zhitao Li
>>
>>
>> +0
>>
>> -----
>>
>> Yan Xu
>>
>>
>> There were no -1 votes.
>>
>>
>> *NOTE: There were a couple known issues [MESOS-5911
>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>
>>
>> Please find the release at:
>>
>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>
>>
>> It is recommended to use a mirror to download the release:
>>
>> http://www.apache.org/dyn/closer.cgi
>>
>>
>> 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
>>
>>
>> The mesos-1.0.0.jar has been released to:
>>
>> https://repository.apache.org
>>
>>
>> The website (http://mesos.apache.org) will be updated shortly to reflect
>> this release.
>>
>>
>> Thanks,
>>
>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vi...@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,
>>>
>>
>>
>
> --
> Text by Jeff, typos by iPhone
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jeff Schroeder <je...@computer.org>.
Small nit but can you s/experimnental/experimental/ under the "Storage"
header in the release post please?
Great work otherwise everyone!
On Wednesday, July 27, 2016, Vinod Kone <vi...@apache.org> wrote:
> Hi all,
>
> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>
>
> +1 (Binding)
>
> ------------------------------
>
> Kapil Arya
>
> Jie Yu
>
> Benjamin Mahler
>
>
> +1 (Non-binding)
>
> ------------------------------
>
> Haosdent
>
> Greg Mann
>
> Zhitao Li
>
>
> +0
>
> -----
>
> Yan Xu
>
>
> There were no -1 votes.
>
>
> *NOTE: There were a couple known issues [MESOS-5911
> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>
>
> Please find the release at:
>
> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>
>
> It is recommended to use a mirror to download the release:
>
> http://www.apache.org/dyn/closer.cgi
>
>
> 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
>
>
> The mesos-1.0.0.jar has been released to:
>
> https://repository.apache.org
>
>
> The website (http://mesos.apache.org) will be updated shortly to reflect
> this release.
>
>
> Thanks,
>
> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vinodkone@apache.org
> <javascript:_e(%7B%7D,'cvml','vinodkone@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,
>>
>
>
--
Text by Jeff, typos by iPhone