You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Vinod Kone <vi...@apache.org> on 2016/07/23 05:40:07 UTC
[VOTE] Release Apache Mesos 1.0.0 (rc4)
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 Jie Yu <yu...@gmail.com>.
+1
sudo make check on CentOS 6/7, Debian 8, Fedora 23, Ubuntu 12/14/15/16
- Jie
On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> One can find the deb/rpm packages here:
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>> And here are the corresponding docker images based off of Ubuntu 14.04:
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> >
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jie Yu <yu...@gmail.com>.
+1
sudo make check on CentOS 6/7, Debian 8, Fedora 23, Ubuntu 12/14/15/16
- Jie
On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> One can find the deb/rpm packages here:
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>> And here are the corresponding docker images based off of Ubuntu 14.04:
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> >
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
+1 sounds good to me. However, if we end up going with (2), I'd commit to
test the new RC and provide a +1 tonight.
On Tue, Jul 26, 2016 at 10:02 PM, Jie Yu <yu...@gmail.com> wrote:
> I prefer 2 if possible. Since this is a UI fix which should be easy to
> validate. I am worried about people trying 1.0.0 because of the blog posts
> without noticing 1.0.1. If 2 does not work, I am OK with 1.
>
>
> On Jul 26, 2016, at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
> We've the ASF press wire and other community blog posts lined up to be
> posted tomorrow, so it will be really hard to tell all those folks to
> postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the
> bug. What do others think? PMC?
>
> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>
>> I don't mind if it's shepherd by folks with more front-end expertise.
>> Actually my original suggested solution on
>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
>> discuss the actual fix on the ticket, I feel that a short term fix
>> shouldn't be more than a few lines to unblock the release.
>>
>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>> think it can be done?
>>
>> - Jie
>>
>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> +1 (non-binding)
>>
>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>
>> test
>>
>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>> executed as part of the whole test suite, and then succeeds on
>>
>> subsequent
>>
>> executions. I'm investigating further, and will file a ticket if
>>
>> necessary.
>>
>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>
>> Cheers,
>> Greg
>>
>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>
>> wrote:
>>
>>
>> One can find the deb/rpm packages here:
>>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>>
>> And here are the corresponding docker images based off of Ubuntu
>>
>> 14.04:
>>
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>>
>>
>>
>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
+1 sounds good to me. However, if we end up going with (2), I'd commit to
test the new RC and provide a +1 tonight.
On Tue, Jul 26, 2016 at 10:02 PM, Jie Yu <yu...@gmail.com> wrote:
> I prefer 2 if possible. Since this is a UI fix which should be easy to
> validate. I am worried about people trying 1.0.0 because of the blog posts
> without noticing 1.0.1. If 2 does not work, I am OK with 1.
>
>
> On Jul 26, 2016, at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
> We've the ASF press wire and other community blog posts lined up to be
> posted tomorrow, so it will be really hard to tell all those folks to
> postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the
> bug. What do others think? PMC?
>
> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>
>> I don't mind if it's shepherd by folks with more front-end expertise.
>> Actually my original suggested solution on
>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
>> discuss the actual fix on the ticket, I feel that a short term fix
>> shouldn't be more than a few lines to unblock the release.
>>
>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>> think it can be done?
>>
>> - Jie
>>
>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> +1 (non-binding)
>>
>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>
>> test
>>
>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>> executed as part of the whole test suite, and then succeeds on
>>
>> subsequent
>>
>> executions. I'm investigating further, and will file a ticket if
>>
>> necessary.
>>
>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>
>> Cheers,
>> Greg
>>
>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>
>> wrote:
>>
>>
>> One can find the deb/rpm packages here:
>>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>>
>> And here are the corresponding docker images based off of Ubuntu
>>
>> 14.04:
>>
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>>
>>
>>
>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jie Yu <yu...@gmail.com>.
I prefer 2 if possible. Since this is a UI fix which should be easy to validate. I am worried about people trying 1.0.0 because of the blog posts without noticing 1.0.1. If 2 does not work, I am OK with 1.
> On Jul 26, 2016, at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
> We've the ASF press wire and other community blog posts lined up to be posted tomorrow, so it will be really hard to tell all those folks to postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the bug. What do others think? PMC?
>
>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>> I don't mind if it's shepherd by folks with more front-end expertise. Actually my original suggested solution on https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's discuss the actual fix on the ticket, I feel that a short term fix shouldn't be more than a few lines to unblock the release.
>>
>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>
>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>> think it can be done?
>>>
>>> - Jie
>>>
>>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>>
>>>> -1
>>>>
>>>> We tested it in our testing environment but webUI redirect didn't work. We
>>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>>
>>>> Given that webUI is the portal for Mesos clusters I feel that we should at
>>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>>> Thoughts?
>>>>
>>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OpenSUSE Tumbleweed:
>>>> ./configure --disable-java --disable-python && make check
>>>>
>>>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>>>>
>>>>> Also tested:
>>>>>
>>>>> make check passes on OS X
>>>>>
>>>>> One thing I found when testing RC4 debian with Aurora integration test
>>>>> suite (on its master) is that scheduler previously expected GPU resource
>>>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>>>> the only scheduler.
>>>>>
>>>>> Given that GPU support is not technically released until 1.0, I don't
>>>>> consider this is a blocker to me, but it might be surprising to people
>>>>> already testing GPU support.
>>>>>
>>>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>> OS X 10.11.6
>>>>>> ./configure --disable-python --disable-java
>>>>>> make check
>>>>>>
>>>>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>>>>
>>>>>>> +1 (non-binding)
>>>>>>>
>>>>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>>>> test
>>>>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>>>>> executed as part of the whole test suite, and then succeeds on
>>>>>> subsequent
>>>>>>> executions. I'm investigating further, and will file a ticket if
>>>>>> necessary.
>>>>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Greg
>>>>>>>
>>>>>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> * make check in CentOS 7.2
>>>>>>>> * make check in Ubuntu 14.04
>>>>>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> One can find the deb/rpm packages here:
>>>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>>>>>>
>>>>>>>>> And here are the corresponding docker images based off of Ubuntu
>>>>>> 14.04:
>>>>>>>>> mesosphere/mesos:1.0.0-rc4
>>>>>>>>> mesosphere/mesos-master:1.0.0-rc4
>>>>>>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>>>>>>
>>>>>>>>> Kapil
>>>>>>>>>
>>>>>>>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Regards,
>>>>>>>> Haosdent Huang
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>
>>>>> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jie Yu <yu...@gmail.com>.
I prefer 2 if possible. Since this is a UI fix which should be easy to validate. I am worried about people trying 1.0.0 because of the blog posts without noticing 1.0.1. If 2 does not work, I am OK with 1.
> On Jul 26, 2016, at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
> We've the ASF press wire and other community blog posts lined up to be posted tomorrow, so it will be really hard to tell all those folks to postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the bug. What do others think? PMC?
>
>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>> I don't mind if it's shepherd by folks with more front-end expertise. Actually my original suggested solution on https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's discuss the actual fix on the ticket, I feel that a short term fix shouldn't be more than a few lines to unblock the release.
>>
>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>
>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>> think it can be done?
>>>
>>> - Jie
>>>
>>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>>
>>>> -1
>>>>
>>>> We tested it in our testing environment but webUI redirect didn't work. We
>>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>>
>>>> Given that webUI is the portal for Mesos clusters I feel that we should at
>>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>>> Thoughts?
>>>>
>>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OpenSUSE Tumbleweed:
>>>> ./configure --disable-java --disable-python && make check
>>>>
>>>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>>>>
>>>>> Also tested:
>>>>>
>>>>> make check passes on OS X
>>>>>
>>>>> One thing I found when testing RC4 debian with Aurora integration test
>>>>> suite (on its master) is that scheduler previously expected GPU resource
>>>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>>>> the only scheduler.
>>>>>
>>>>> Given that GPU support is not technically released until 1.0, I don't
>>>>> consider this is a blocker to me, but it might be surprising to people
>>>>> already testing GPU support.
>>>>>
>>>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>> OS X 10.11.6
>>>>>> ./configure --disable-python --disable-java
>>>>>> make check
>>>>>>
>>>>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>>>>
>>>>>>> +1 (non-binding)
>>>>>>>
>>>>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>>>> test
>>>>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>>>>> executed as part of the whole test suite, and then succeeds on
>>>>>> subsequent
>>>>>>> executions. I'm investigating further, and will file a ticket if
>>>>>> necessary.
>>>>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Greg
>>>>>>>
>>>>>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> * make check in CentOS 7.2
>>>>>>>> * make check in Ubuntu 14.04
>>>>>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> One can find the deb/rpm packages here:
>>>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>>>>>>
>>>>>>>>> And here are the corresponding docker images based off of Ubuntu
>>>>>> 14.04:
>>>>>>>>> mesosphere/mesos:1.0.0-rc4
>>>>>>>>> mesosphere/mesos-master:1.0.0-rc4
>>>>>>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>>>>>>
>>>>>>>>> Kapil
>>>>>>>>>
>>>>>>>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Regards,
>>>>>>>> Haosdent Huang
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>
>>>>> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@apache.org>.
Thanks Yan. I will release 1.0 and call out the known issues. We will start
the prep for a 1.0.1 later this week.
On Tue, Jul 26, 2016 at 7:32 PM, Yan Xu <xu...@apple.com> wrote:
> I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or
> 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call
> out the known issue.
>
> > On Jul 26, 2016, at 7:09 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
> >
> > I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
> > suggest either we:
> > 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
> > then cut 1.0.1 soon after with this and other fixes.
> > 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather
> than
> > an official release. After 72hrs we can hopefully call rc5 the official
> 1.0
> > (or maybe more blockers come up). We could have more blogs/press then
> about
> > the official 1.0 release.
> > 1c) push the press releases and announcements out a few more days. Not
> sure
> > if this is possible at this point?
> > I'd prefer 1c) if possible, or a/b otherwise.
> >
> > On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
> > benjamin.hindman@gmail.com> wrote:
> >
> >> I agree with Vinod that we should go with option 1. I think redirect is
> a
> >> valuable feature but it's not imperative for the operation of the
> cluster.
> >>
> >> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org>
> wrote:
> >>
> >>> We've the ASF press wire and other community blog posts lined up to be
> >>> posted tomorrow, so it will be really hard to tell all those folks to
> >>> postpone it this late. I've a couple options that I want to propose
> >>>
> >>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
> >>> bug.
> >>>
> >>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> >>> tonight without doing the typical 72 hour voting period.
> >>>
> >>>
> >>> I'm personally leaning towards 1) given the timing and the nature of
> the
> >>> bug. What do others think? PMC?
> >>>
> >>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
> >>>
> >>>> I don't mind if it's shepherd by folks with more front-end expertise.
> >>>> Actually my original suggested solution on
> >>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
> >>>> Let's discuss the actual fix on the ticket, I feel that a short term
> fix
> >>>> shouldn't be more than a few lines to unblock the release.
> >>>>
> >>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
> >>>>
> >>>> Yan, are you going to shepherd the fix for this one? If yes, when do
> you
> >>>> think it can be done?
> >>>>
> >>>> - Jie
> >>>>
> >>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
> >>>>
> >>>> -1
> >>>>
> >>>> We tested it in our testing environment but webUI redirect didn't
> work.
> >>>> We
> >>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
> >>>>
> >>>> Given that webUI is the portal for Mesos clusters I feel that we
> should
> >>>> at
> >>>> least have a basic fix (more context in the JIRA) before release 1.0.
> >>>> Thoughts?
> >>>>
> >>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> >>>>
> >>>> +1 (binding)
> >>>>
> >>>> OpenSUSE Tumbleweed:
> >>>> ./configure --disable-java --disable-python && make check
> >>>>
> >>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Also tested:
> >>>>
> >>>> make check passes on OS X
> >>>>
> >>>> One thing I found when testing RC4 debian with Aurora integration test
> >>>> suite (on its master) is that scheduler previously expected GPU
> resource
> >>>> will not receive offers without new `GPU_RESOURCES` capability even
> it's
> >>>> the only scheduler.
> >>>>
> >>>> Given that GPU support is not technically released until 1.0, I don't
> >>>> consider this is a blocker to me, but it might be surprising to people
> >>>> already testing GPU support.
> >>>>
> >>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bmahler@apache.org
> >
> >>>> wrote:
> >>>>
> >>>> +1 (binding)
> >>>>
> >>>> OS X 10.11.6
> >>>> ./configure --disable-python --disable-java
> >>>> make check
> >>>>
> >>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io>
> wrote:
> >>>>
> >>>> +1 (non-binding)
> >>>>
> >>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
> >>>>
> >>>> test
> >>>>
> >>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
> >>>> executed as part of the whole test suite, and then succeeds on
> >>>>
> >>>> subsequent
> >>>>
> >>>> executions. I'm investigating further, and will file a ticket if
> >>>>
> >>>> necessary.
> >>>>
> >>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >>>>
> >>>> Cheers,
> >>>> Greg
> >>>>
> >>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> * make check in CentOS 7.2
> >>>> * make check in Ubuntu 14.04
> >>>> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>>>
> >>>>
> >>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
> >>>>
> >>>> wrote:
> >>>>
> >>>>
> >>>> One can find the deb/rpm packages here:
> >>>>
> >>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >>>>
> >>>>
> >>>> And here are the corresponding docker images based off of Ubuntu
> >>>>
> >>>> 14.04:
> >>>>
> >>>> mesosphere/mesos:1.0.0-rc4
> >>>> mesosphere/mesos-master:1.0.0-rc4
> >>>> mesosphere/mesos-slave:1.0.0-rc4
> >>>>
> >>>> Kapil
> >>>>
> >>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards,
> >>>> Haosdent Huang
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>
> >>>> Zhitao Li
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@apache.org>.
Thanks Yan. I will release 1.0 and call out the known issues. We will start
the prep for a 1.0.1 later this week.
On Tue, Jul 26, 2016 at 7:32 PM, Yan Xu <xu...@apple.com> wrote:
> I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or
> 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call
> out the known issue.
>
> > On Jul 26, 2016, at 7:09 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
> >
> > I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
> > suggest either we:
> > 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
> > then cut 1.0.1 soon after with this and other fixes.
> > 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather
> than
> > an official release. After 72hrs we can hopefully call rc5 the official
> 1.0
> > (or maybe more blockers come up). We could have more blogs/press then
> about
> > the official 1.0 release.
> > 1c) push the press releases and announcements out a few more days. Not
> sure
> > if this is possible at this point?
> > I'd prefer 1c) if possible, or a/b otherwise.
> >
> > On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
> > benjamin.hindman@gmail.com> wrote:
> >
> >> I agree with Vinod that we should go with option 1. I think redirect is
> a
> >> valuable feature but it's not imperative for the operation of the
> cluster.
> >>
> >> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org>
> wrote:
> >>
> >>> We've the ASF press wire and other community blog posts lined up to be
> >>> posted tomorrow, so it will be really hard to tell all those folks to
> >>> postpone it this late. I've a couple options that I want to propose
> >>>
> >>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
> >>> bug.
> >>>
> >>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> >>> tonight without doing the typical 72 hour voting period.
> >>>
> >>>
> >>> I'm personally leaning towards 1) given the timing and the nature of
> the
> >>> bug. What do others think? PMC?
> >>>
> >>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
> >>>
> >>>> I don't mind if it's shepherd by folks with more front-end expertise.
> >>>> Actually my original suggested solution on
> >>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
> >>>> Let's discuss the actual fix on the ticket, I feel that a short term
> fix
> >>>> shouldn't be more than a few lines to unblock the release.
> >>>>
> >>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
> >>>>
> >>>> Yan, are you going to shepherd the fix for this one? If yes, when do
> you
> >>>> think it can be done?
> >>>>
> >>>> - Jie
> >>>>
> >>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
> >>>>
> >>>> -1
> >>>>
> >>>> We tested it in our testing environment but webUI redirect didn't
> work.
> >>>> We
> >>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
> >>>>
> >>>> Given that webUI is the portal for Mesos clusters I feel that we
> should
> >>>> at
> >>>> least have a basic fix (more context in the JIRA) before release 1.0.
> >>>> Thoughts?
> >>>>
> >>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> >>>>
> >>>> +1 (binding)
> >>>>
> >>>> OpenSUSE Tumbleweed:
> >>>> ./configure --disable-java --disable-python && make check
> >>>>
> >>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Also tested:
> >>>>
> >>>> make check passes on OS X
> >>>>
> >>>> One thing I found when testing RC4 debian with Aurora integration test
> >>>> suite (on its master) is that scheduler previously expected GPU
> resource
> >>>> will not receive offers without new `GPU_RESOURCES` capability even
> it's
> >>>> the only scheduler.
> >>>>
> >>>> Given that GPU support is not technically released until 1.0, I don't
> >>>> consider this is a blocker to me, but it might be surprising to people
> >>>> already testing GPU support.
> >>>>
> >>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bmahler@apache.org
> >
> >>>> wrote:
> >>>>
> >>>> +1 (binding)
> >>>>
> >>>> OS X 10.11.6
> >>>> ./configure --disable-python --disable-java
> >>>> make check
> >>>>
> >>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io>
> wrote:
> >>>>
> >>>> +1 (non-binding)
> >>>>
> >>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
> >>>>
> >>>> test
> >>>>
> >>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
> >>>> executed as part of the whole test suite, and then succeeds on
> >>>>
> >>>> subsequent
> >>>>
> >>>> executions. I'm investigating further, and will file a ticket if
> >>>>
> >>>> necessary.
> >>>>
> >>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >>>>
> >>>> Cheers,
> >>>> Greg
> >>>>
> >>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> * make check in CentOS 7.2
> >>>> * make check in Ubuntu 14.04
> >>>> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>>>
> >>>>
> >>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
> >>>>
> >>>> wrote:
> >>>>
> >>>>
> >>>> One can find the deb/rpm packages here:
> >>>>
> >>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >>>>
> >>>>
> >>>> And here are the corresponding docker images based off of Ubuntu
> >>>>
> >>>> 14.04:
> >>>>
> >>>> mesosphere/mesos:1.0.0-rc4
> >>>> mesosphere/mesos-master:1.0.0-rc4
> >>>> mesosphere/mesos-slave:1.0.0-rc4
> >>>>
> >>>> Kapil
> >>>>
> >>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards,
> >>>> Haosdent Huang
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>
> >>>> Zhitao Li
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call out the known issue.
> On Jul 26, 2016, at 7:09 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
>
> I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
> suggest either we:
> 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
> then cut 1.0.1 soon after with this and other fixes.
> 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than
> an official release. After 72hrs we can hopefully call rc5 the official 1.0
> (or maybe more blockers come up). We could have more blogs/press then about
> the official 1.0 release.
> 1c) push the press releases and announcements out a few more days. Not sure
> if this is possible at this point?
> I'd prefer 1c) if possible, or a/b otherwise.
>
> On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
> benjamin.hindman@gmail.com> wrote:
>
>> I agree with Vinod that we should go with option 1. I think redirect is a
>> valuable feature but it's not imperative for the operation of the cluster.
>>
>> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>>
>>> We've the ASF press wire and other community blog posts lined up to be
>>> posted tomorrow, so it will be really hard to tell all those folks to
>>> postpone it this late. I've a couple options that I want to propose
>>>
>>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
>>> bug.
>>>
>>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
>>> tonight without doing the typical 72 hour voting period.
>>>
>>>
>>> I'm personally leaning towards 1) given the timing and the nature of the
>>> bug. What do others think? PMC?
>>>
>>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>>>
>>>> I don't mind if it's shepherd by folks with more front-end expertise.
>>>> Actually my original suggested solution on
>>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
>>>> Let's discuss the actual fix on the ticket, I feel that a short term fix
>>>> shouldn't be more than a few lines to unblock the release.
>>>>
>>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>>
>>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>>> think it can be done?
>>>>
>>>> - Jie
>>>>
>>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>>
>>>> -1
>>>>
>>>> We tested it in our testing environment but webUI redirect didn't work.
>>>> We
>>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>>
>>>> Given that webUI is the portal for Mesos clusters I feel that we should
>>>> at
>>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>>> Thoughts?
>>>>
>>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OpenSUSE Tumbleweed:
>>>> ./configure --disable-java --disable-python && make check
>>>>
>>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
>>>> wrote:
>>>>
>>>> Also tested:
>>>>
>>>> make check passes on OS X
>>>>
>>>> One thing I found when testing RC4 debian with Aurora integration test
>>>> suite (on its master) is that scheduler previously expected GPU resource
>>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>>> the only scheduler.
>>>>
>>>> Given that GPU support is not technically released until 1.0, I don't
>>>> consider this is a blocker to me, but it might be surprising to people
>>>> already testing GPU support.
>>>>
>>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>>> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OS X 10.11.6
>>>> ./configure --disable-python --disable-java
>>>> make check
>>>>
>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>
>>>> +1 (non-binding)
>>>>
>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>>
>>>> test
>>>>
>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>> executed as part of the whole test suite, and then succeeds on
>>>>
>>>> subsequent
>>>>
>>>> executions. I'm investigating further, and will file a ticket if
>>>>
>>>> necessary.
>>>>
>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>
>>>> Cheers,
>>>> Greg
>>>>
>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>> * make check in CentOS 7.2
>>>> * make check in Ubuntu 14.04
>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>
>>>>
>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>>
>>>> wrote:
>>>>
>>>>
>>>> One can find the deb/rpm packages here:
>>>>
>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>
>>>>
>>>> And here are the corresponding docker images based off of Ubuntu
>>>>
>>>> 14.04:
>>>>
>>>> mesosphere/mesos:1.0.0-rc4
>>>> mesosphere/mesos-master:1.0.0-rc4
>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>
>>>> Kapil
>>>>
>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Haosdent Huang
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>
>>>> Zhitao Li
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call out the known issue.
> On Jul 26, 2016, at 7:09 PM, Adam Bordelon <ad...@mesosphere.io> wrote:
>
> I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
> suggest either we:
> 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
> then cut 1.0.1 soon after with this and other fixes.
> 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than
> an official release. After 72hrs we can hopefully call rc5 the official 1.0
> (or maybe more blockers come up). We could have more blogs/press then about
> the official 1.0 release.
> 1c) push the press releases and announcements out a few more days. Not sure
> if this is possible at this point?
> I'd prefer 1c) if possible, or a/b otherwise.
>
> On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
> benjamin.hindman@gmail.com> wrote:
>
>> I agree with Vinod that we should go with option 1. I think redirect is a
>> valuable feature but it's not imperative for the operation of the cluster.
>>
>> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>>
>>> We've the ASF press wire and other community blog posts lined up to be
>>> posted tomorrow, so it will be really hard to tell all those folks to
>>> postpone it this late. I've a couple options that I want to propose
>>>
>>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
>>> bug.
>>>
>>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
>>> tonight without doing the typical 72 hour voting period.
>>>
>>>
>>> I'm personally leaning towards 1) given the timing and the nature of the
>>> bug. What do others think? PMC?
>>>
>>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>>>
>>>> I don't mind if it's shepherd by folks with more front-end expertise.
>>>> Actually my original suggested solution on
>>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
>>>> Let's discuss the actual fix on the ticket, I feel that a short term fix
>>>> shouldn't be more than a few lines to unblock the release.
>>>>
>>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>>
>>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>>> think it can be done?
>>>>
>>>> - Jie
>>>>
>>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>>
>>>> -1
>>>>
>>>> We tested it in our testing environment but webUI redirect didn't work.
>>>> We
>>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>>
>>>> Given that webUI is the portal for Mesos clusters I feel that we should
>>>> at
>>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>>> Thoughts?
>>>>
>>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OpenSUSE Tumbleweed:
>>>> ./configure --disable-java --disable-python && make check
>>>>
>>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
>>>> wrote:
>>>>
>>>> Also tested:
>>>>
>>>> make check passes on OS X
>>>>
>>>> One thing I found when testing RC4 debian with Aurora integration test
>>>> suite (on its master) is that scheduler previously expected GPU resource
>>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>>> the only scheduler.
>>>>
>>>> Given that GPU support is not technically released until 1.0, I don't
>>>> consider this is a blocker to me, but it might be surprising to people
>>>> already testing GPU support.
>>>>
>>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>>> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> OS X 10.11.6
>>>> ./configure --disable-python --disable-java
>>>> make check
>>>>
>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>
>>>> +1 (non-binding)
>>>>
>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>>
>>>> test
>>>>
>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>> executed as part of the whole test suite, and then succeeds on
>>>>
>>>> subsequent
>>>>
>>>> executions. I'm investigating further, and will file a ticket if
>>>>
>>>> necessary.
>>>>
>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>
>>>> Cheers,
>>>> Greg
>>>>
>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>> * make check in CentOS 7.2
>>>> * make check in Ubuntu 14.04
>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>
>>>>
>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>>
>>>> wrote:
>>>>
>>>>
>>>> One can find the deb/rpm packages here:
>>>>
>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>
>>>>
>>>> And here are the corresponding docker images based off of Ubuntu
>>>>
>>>> 14.04:
>>>>
>>>> mesosphere/mesos:1.0.0-rc4
>>>> mesosphere/mesos-master:1.0.0-rc4
>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>
>>>> Kapil
>>>>
>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Haosdent Huang
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>
>>>> Zhitao Li
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Adam Bordelon <ad...@mesosphere.io>.
I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
suggest either we:
1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
then cut 1.0.1 soon after with this and other fixes.
1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than
an official release. After 72hrs we can hopefully call rc5 the official 1.0
(or maybe more blockers come up). We could have more blogs/press then about
the official 1.0 release.
1c) push the press releases and announcements out a few more days. Not sure
if this is possible at this point?
I'd prefer 1c) if possible, or a/b otherwise.
On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
benjamin.hindman@gmail.com> wrote:
> I agree with Vinod that we should go with option 1. I think redirect is a
> valuable feature but it's not imperative for the operation of the cluster.
>
> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> We've the ASF press wire and other community blog posts lined up to be
>> posted tomorrow, so it will be really hard to tell all those folks to
>> postpone it this late. I've a couple options that I want to propose
>>
>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
>> bug.
>>
>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
>> tonight without doing the typical 72 hour voting period.
>>
>>
>> I'm personally leaning towards 1) given the timing and the nature of the
>> bug. What do others think? PMC?
>>
>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>>
>>> I don't mind if it's shepherd by folks with more front-end expertise.
>>> Actually my original suggested solution on
>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
>>> Let's discuss the actual fix on the ticket, I feel that a short term fix
>>> shouldn't be more than a few lines to unblock the release.
>>>
>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>
>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>> think it can be done?
>>>
>>> - Jie
>>>
>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>
>>> -1
>>>
>>> We tested it in our testing environment but webUI redirect didn't work.
>>> We
>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>
>>> Given that webUI is the portal for Mesos clusters I feel that we should
>>> at
>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>> Thoughts?
>>>
>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>
>>> +1 (binding)
>>>
>>> OpenSUSE Tumbleweed:
>>> ./configure --disable-java --disable-python && make check
>>>
>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>> Also tested:
>>>
>>> make check passes on OS X
>>>
>>> One thing I found when testing RC4 debian with Aurora integration test
>>> suite (on its master) is that scheduler previously expected GPU resource
>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>> the only scheduler.
>>>
>>> Given that GPU support is not technically released until 1.0, I don't
>>> consider this is a blocker to me, but it might be surprising to people
>>> already testing GPU support.
>>>
>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>> wrote:
>>>
>>> +1 (binding)
>>>
>>> OS X 10.11.6
>>> ./configure --disable-python --disable-java
>>> make check
>>>
>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>
>>> +1 (non-binding)
>>>
>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>
>>> test
>>>
>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>> executed as part of the whole test suite, and then succeeds on
>>>
>>> subsequent
>>>
>>> executions. I'm investigating further, and will file a ticket if
>>>
>>> necessary.
>>>
>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> * make check in CentOS 7.2
>>> * make check in Ubuntu 14.04
>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>
>>>
>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>
>>> wrote:
>>>
>>>
>>> One can find the deb/rpm packages here:
>>>
>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>
>>>
>>> And here are the corresponding docker images based off of Ubuntu
>>>
>>> 14.04:
>>>
>>> mesosphere/mesos:1.0.0-rc4
>>> mesosphere/mesos-master:1.0.0-rc4
>>> mesosphere/mesos-slave:1.0.0-rc4
>>>
>>> Kapil
>>>
>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Adam Bordelon <ad...@mesosphere.io>.
I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
suggest either we:
1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
then cut 1.0.1 soon after with this and other fixes.
1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than
an official release. After 72hrs we can hopefully call rc5 the official 1.0
(or maybe more blockers come up). We could have more blogs/press then about
the official 1.0 release.
1c) push the press releases and announcements out a few more days. Not sure
if this is possible at this point?
I'd prefer 1c) if possible, or a/b otherwise.
On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
benjamin.hindman@gmail.com> wrote:
> I agree with Vinod that we should go with option 1. I think redirect is a
> valuable feature but it's not imperative for the operation of the cluster.
>
> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> We've the ASF press wire and other community blog posts lined up to be
>> posted tomorrow, so it will be really hard to tell all those folks to
>> postpone it this late. I've a couple options that I want to propose
>>
>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
>> bug.
>>
>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
>> tonight without doing the typical 72 hour voting period.
>>
>>
>> I'm personally leaning towards 1) given the timing and the nature of the
>> bug. What do others think? PMC?
>>
>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>>
>>> I don't mind if it's shepherd by folks with more front-end expertise.
>>> Actually my original suggested solution on
>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
>>> Let's discuss the actual fix on the ticket, I feel that a short term fix
>>> shouldn't be more than a few lines to unblock the release.
>>>
>>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>>
>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>> think it can be done?
>>>
>>> - Jie
>>>
>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>>
>>> -1
>>>
>>> We tested it in our testing environment but webUI redirect didn't work.
>>> We
>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>
>>> Given that webUI is the portal for Mesos clusters I feel that we should
>>> at
>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>> Thoughts?
>>>
>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>
>>> +1 (binding)
>>>
>>> OpenSUSE Tumbleweed:
>>> ./configure --disable-java --disable-python && make check
>>>
>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>> Also tested:
>>>
>>> make check passes on OS X
>>>
>>> One thing I found when testing RC4 debian with Aurora integration test
>>> suite (on its master) is that scheduler previously expected GPU resource
>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>> the only scheduler.
>>>
>>> Given that GPU support is not technically released until 1.0, I don't
>>> consider this is a blocker to me, but it might be surprising to people
>>> already testing GPU support.
>>>
>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>> wrote:
>>>
>>> +1 (binding)
>>>
>>> OS X 10.11.6
>>> ./configure --disable-python --disable-java
>>> make check
>>>
>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>
>>> +1 (non-binding)
>>>
>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>
>>> test
>>>
>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>> executed as part of the whole test suite, and then succeeds on
>>>
>>> subsequent
>>>
>>> executions. I'm investigating further, and will file a ticket if
>>>
>>> necessary.
>>>
>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> * make check in CentOS 7.2
>>> * make check in Ubuntu 14.04
>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>
>>>
>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>
>>> wrote:
>>>
>>>
>>> One can find the deb/rpm packages here:
>>>
>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>
>>>
>>> And here are the corresponding docker images based off of Ubuntu
>>>
>>> 14.04:
>>>
>>> mesosphere/mesos:1.0.0-rc4
>>> mesosphere/mesos-master:1.0.0-rc4
>>> mesosphere/mesos-slave:1.0.0-rc4
>>>
>>> Kapil
>>>
>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Benjamin Hindman <be...@gmail.com>.
I agree with Vinod that we should go with option 1. I think redirect is a
valuable feature but it's not imperative for the operation of the cluster.
On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
> We've the ASF press wire and other community blog posts lined up to be
> posted tomorrow, so it will be really hard to tell all those folks to
> postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the
> bug. What do others think? PMC?
>
> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>
>> I don't mind if it's shepherd by folks with more front-end expertise.
>> Actually my original suggested solution on
>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
>> discuss the actual fix on the ticket, I feel that a short term fix
>> shouldn't be more than a few lines to unblock the release.
>>
>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>> think it can be done?
>>
>> - Jie
>>
>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> +1 (non-binding)
>>
>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>
>> test
>>
>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>> executed as part of the whole test suite, and then succeeds on
>>
>> subsequent
>>
>> executions. I'm investigating further, and will file a ticket if
>>
>> necessary.
>>
>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>
>> Cheers,
>> Greg
>>
>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>
>> wrote:
>>
>>
>> One can find the deb/rpm packages here:
>>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>>
>> And here are the corresponding docker images based off of Ubuntu
>>
>> 14.04:
>>
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>>
>>
>>
>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Benjamin Hindman <be...@gmail.com>.
I agree with Vinod that we should go with option 1. I think redirect is a
valuable feature but it's not imperative for the operation of the cluster.
On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <vi...@apache.org> wrote:
> We've the ASF press wire and other community blog posts lined up to be
> posted tomorrow, so it will be really hard to tell all those folks to
> postpone it this late. I've a couple options that I want to propose
>
> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
>
> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
> tonight without doing the typical 72 hour voting period.
>
>
> I'm personally leaning towards 1) given the timing and the nature of the
> bug. What do others think? PMC?
>
> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
>
>> I don't mind if it's shepherd by folks with more front-end expertise.
>> Actually my original suggested solution on
>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
>> discuss the actual fix on the ticket, I feel that a short term fix
>> shouldn't be more than a few lines to unblock the release.
>>
>> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>> think it can be done?
>>
>> - Jie
>>
>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> +1 (non-binding)
>>
>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>
>> test
>>
>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>> executed as part of the whole test suite, and then succeeds on
>>
>> subsequent
>>
>> executions. I'm investigating further, and will file a ticket if
>>
>> necessary.
>>
>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>
>> Cheers,
>> Greg
>>
>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>
>> wrote:
>>
>>
>> One can find the deb/rpm packages here:
>>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>
>>
>> And here are the corresponding docker images based off of Ubuntu
>>
>> 14.04:
>>
>> mesosphere/mesos:1.0.0-rc4
>> mesosphere/mesos-master:1.0.0-rc4
>> mesosphere/mesos-slave:1.0.0-rc4
>>
>> Kapil
>>
>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>>
>>
>>
>>
>>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@apache.org>.
We've the ASF press wire and other community blog posts lined up to be
posted tomorrow, so it will be really hard to tell all those folks to
postpone it this late. I've a couple options that I want to propose
1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
tonight without doing the typical 72 hour voting period.
I'm personally leaning towards 1) given the timing and the nature of the
bug. What do others think? PMC?
On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
> I don't mind if it's shepherd by folks with more front-end expertise.
> Actually my original suggested solution on
> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
> discuss the actual fix on the ticket, I feel that a short term fix
> shouldn't be more than a few lines to unblock the release.
>
> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>
> Yan, are you going to shepherd the fix for this one? If yes, when do you
> think it can be done?
>
> - Jie
>
> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>
> -1
>
> We tested it in our testing environment but webUI redirect didn't work. We
> filed: https://issues.apache.org/jira/browse/MESOS-5911
>
> Given that webUI is the portal for Mesos clusters I feel that we should at
> least have a basic fix (more context in the JIRA) before release 1.0.
> Thoughts?
>
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test
> suite (on its master) is that scheduler previously expected GPU resource
> will not receive offers without new `GPU_RESOURCES` capability even it's
> the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't
> consider this is a blocker to me, but it might be surprising to people
> already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
> +1 (non-binding)
>
> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>
> test
>
> failure: ExamplesTest.PythonFramework fails for me the first time it's
> executed as part of the whole test suite, and then succeeds on
>
> subsequent
>
> executions. I'm investigating further, and will file a ticket if
>
> necessary.
>
> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>
> Cheers,
> Greg
>
> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>
> wrote:
>
>
> One can find the deb/rpm packages here:
>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>
>
> And here are the corresponding docker images based off of Ubuntu
>
> 14.04:
>
> mesosphere/mesos:1.0.0-rc4
> mesosphere/mesos-master:1.0.0-rc4
> mesosphere/mesos-slave:1.0.0-rc4
>
> Kapil
>
> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
>
>
>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
>
>
>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Vinod Kone <vi...@apache.org>.
We've the ASF press wire and other community blog posts lined up to be
posted tomorrow, so it will be really hard to tell all those folks to
postpone it this late. I've a couple options that I want to propose
1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug.
2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
tonight without doing the typical 72 hour voting period.
I'm personally leaning towards 1) given the timing and the nature of the
bug. What do others think? PMC?
On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xu...@apple.com> wrote:
> I don't mind if it's shepherd by folks with more front-end expertise.
> Actually my original suggested solution on
> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect. Let's
> discuss the actual fix on the ticket, I feel that a short term fix
> shouldn't be more than a few lines to unblock the release.
>
> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>
> Yan, are you going to shepherd the fix for this one? If yes, when do you
> think it can be done?
>
> - Jie
>
> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>
> -1
>
> We tested it in our testing environment but webUI redirect didn't work. We
> filed: https://issues.apache.org/jira/browse/MESOS-5911
>
> Given that webUI is the portal for Mesos clusters I feel that we should at
> least have a basic fix (more context in the JIRA) before release 1.0.
> Thoughts?
>
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test
> suite (on its master) is that scheduler previously expected GPU resource
> will not receive offers without new `GPU_RESOURCES` capability even it's
> the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't
> consider this is a blocker to me, but it might be surprising to people
> already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
> +1 (non-binding)
>
> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>
> test
>
> failure: ExamplesTest.PythonFramework fails for me the first time it's
> executed as part of the whole test suite, and then succeeds on
>
> subsequent
>
> executions. I'm investigating further, and will file a ticket if
>
> necessary.
>
> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>
> Cheers,
> Greg
>
> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>
> wrote:
>
>
> One can find the deb/rpm packages here:
>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>
>
> And here are the corresponding docker images based off of Ubuntu
>
> 14.04:
>
> mesosphere/mesos:1.0.0-rc4
> mesosphere/mesos-master:1.0.0-rc4
> mesosphere/mesos-slave:1.0.0-rc4
>
> Kapil
>
> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
>
>
>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
>
>
>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
I don't mind if it's shepherd by folks with more front-end expertise. Actually my original suggested solution on https://issues.apache.org/jira/browse/MESOS-5911 <https://issues.apache.org/jira/browse/MESOS-5911> seemed incorrect. Let's discuss the actual fix on the ticket, I feel that a short term fix shouldn't be more than a few lines to unblock the release.
> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>
> Yan, are you going to shepherd the fix for this one? If yes, when do you
> think it can be done?
>
> - Jie
>
> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>>> Also tested:
>>>
>>> make check passes on OS X
>>>
>>> One thing I found when testing RC4 debian with Aurora integration test
>>> suite (on its master) is that scheduler previously expected GPU resource
>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>> the only scheduler.
>>>
>>> Given that GPU support is not technically released until 1.0, I don't
>>> consider this is a blocker to me, but it might be surprising to people
>>> already testing GPU support.
>>>
>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>> wrote:
>>>
>>>> +1 (binding)
>>>>
>>>> OS X 10.11.6
>>>> ./configure --disable-python --disable-java
>>>> make check
>>>>
>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>
>>>>> +1 (non-binding)
>>>>>
>>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>> test
>>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>>> executed as part of the whole test suite, and then succeeds on
>>>> subsequent
>>>>> executions. I'm investigating further, and will file a ticket if
>>>> necessary.
>>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>>
>>>>> Cheers,
>>>>> Greg
>>>>>
>>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> * make check in CentOS 7.2
>>>>>> * make check in Ubuntu 14.04
>>>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>>>>
>>>>>>> One can find the deb/rpm packages here:
>>>>>>>
>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>>>>
>>>>>>> And here are the corresponding docker images based off of Ubuntu
>>>> 14.04:
>>>>>>> mesosphere/mesos:1.0.0-rc4
>>>>>>> mesosphere/mesos-master:1.0.0-rc4
>>>>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>>>>
>>>>>>> Kapil
>>>>>>>
>>>>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Haosdent Huang
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
I don't mind if it's shepherd by folks with more front-end expertise. Actually my original suggested solution on https://issues.apache.org/jira/browse/MESOS-5911 <https://issues.apache.org/jira/browse/MESOS-5911> seemed incorrect. Let's discuss the actual fix on the ticket, I feel that a short term fix shouldn't be more than a few lines to unblock the release.
> On Jul 26, 2016, at 3:26 PM, Jie Yu <yu...@gmail.com> wrote:
>
> Yan, are you going to shepherd the fix for this one? If yes, when do you
> think it can be done?
>
> - Jie
>
> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
>
>> -1
>>
>> We tested it in our testing environment but webUI redirect didn't work. We
>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>
>> Given that webUI is the portal for Mesos clusters I feel that we should at
>> least have a basic fix (more context in the JIRA) before release 1.0.
>> Thoughts?
>>
>> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> +1 (binding)
>>
>> OpenSUSE Tumbleweed:
>> ./configure --disable-java --disable-python && make check
>>
>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>>> Also tested:
>>>
>>> make check passes on OS X
>>>
>>> One thing I found when testing RC4 debian with Aurora integration test
>>> suite (on its master) is that scheduler previously expected GPU resource
>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>> the only scheduler.
>>>
>>> Given that GPU support is not technically released until 1.0, I don't
>>> consider this is a blocker to me, but it might be surprising to people
>>> already testing GPU support.
>>>
>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>>> wrote:
>>>
>>>> +1 (binding)
>>>>
>>>> OS X 10.11.6
>>>> ./configure --disable-python --disable-java
>>>> make check
>>>>
>>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>>
>>>>> +1 (non-binding)
>>>>>
>>>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>> test
>>>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>>>> executed as part of the whole test suite, and then succeeds on
>>>> subsequent
>>>>> executions. I'm investigating further, and will file a ticket if
>>>> necessary.
>>>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>>>
>>>>> Cheers,
>>>>> Greg
>>>>>
>>>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> * make check in CentOS 7.2
>>>>>> * make check in Ubuntu 14.04
>>>>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>>>>
>>>>>>> One can find the deb/rpm packages here:
>>>>>>>
>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>>>>>
>>>>>>> And here are the corresponding docker images based off of Ubuntu
>>>> 14.04:
>>>>>>> mesosphere/mesos:1.0.0-rc4
>>>>>>> mesosphere/mesos-master:1.0.0-rc4
>>>>>>> mesosphere/mesos-slave:1.0.0-rc4
>>>>>>>
>>>>>>> Kapil
>>>>>>>
>>>>>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Haosdent Huang
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jie Yu <yu...@gmail.com>.
Yan, are you going to shepherd the fix for this one? If yes, when do you
think it can be done?
- Jie
On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
> -1
>
> We tested it in our testing environment but webUI redirect didn't work. We
> filed: https://issues.apache.org/jira/browse/MESOS-5911
>
> Given that webUI is the portal for Mesos clusters I feel that we should at
> least have a basic fix (more context in the JIRA) before release 1.0.
> Thoughts?
>
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>>> +1 (binding)
>>>
>>> OS X 10.11.6
>>> ./configure --disable-python --disable-java
>>> make check
>>>
>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>
>>> > +1 (non-binding)
>>> >
>>> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>> test
>>> > failure: ExamplesTest.PythonFramework fails for me the first time it's
>>> > executed as part of the whole test suite, and then succeeds on
>>> subsequent
>>> > executions. I'm investigating further, and will file a ticket if
>>> necessary.
>>> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>> >
>>> > Cheers,
>>> > Greg
>>> >
>>> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>> >
>>> >> +1
>>> >>
>>> >> * make check in CentOS 7.2
>>> >> * make check in Ubuntu 14.04
>>> >> * test upgrade from 0.28.2 to 1.0.0-rc4
>>> >>
>>> >>
>>> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>> >>
>>> >> > One can find the deb/rpm packages here:
>>> >> >
>>> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>> >> >
>>> >> > And here are the corresponding docker images based off of Ubuntu
>>> 14.04:
>>> >> > mesosphere/mesos:1.0.0-rc4
>>> >> > mesosphere/mesos-master:1.0.0-rc4
>>> >> > mesosphere/mesos-slave:1.0.0-rc4
>>> >> >
>>> >> > Kapil
>>> >> >
>>> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Best Regards,
>>> >> Haosdent Huang
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Jie Yu <yu...@gmail.com>.
Yan, are you going to shepherd the fix for this one? If yes, when do you
think it can be done?
- Jie
On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <xu...@apple.com> wrote:
> -1
>
> We tested it in our testing environment but webUI redirect didn't work. We
> filed: https://issues.apache.org/jira/browse/MESOS-5911
>
> Given that webUI is the portal for Mesos clusters I feel that we should at
> least have a basic fix (more context in the JIRA) before release 1.0.
> Thoughts?
>
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
>
>> Also tested:
>>
>> make check passes on OS X
>>
>> One thing I found when testing RC4 debian with Aurora integration test
>> suite (on its master) is that scheduler previously expected GPU resource
>> will not receive offers without new `GPU_RESOURCES` capability even it's
>> the only scheduler.
>>
>> Given that GPU support is not technically released until 1.0, I don't
>> consider this is a blocker to me, but it might be surprising to people
>> already testing GPU support.
>>
>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>>> +1 (binding)
>>>
>>> OS X 10.11.6
>>> ./configure --disable-python --disable-java
>>> make check
>>>
>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>>
>>> > +1 (non-binding)
>>> >
>>> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>> test
>>> > failure: ExamplesTest.PythonFramework fails for me the first time it's
>>> > executed as part of the whole test suite, and then succeeds on
>>> subsequent
>>> > executions. I'm investigating further, and will file a ticket if
>>> necessary.
>>> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>> >
>>> > Cheers,
>>> > Greg
>>> >
>>> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>>> >
>>> >> +1
>>> >>
>>> >> * make check in CentOS 7.2
>>> >> * make check in Ubuntu 14.04
>>> >> * test upgrade from 0.28.2 to 1.0.0-rc4
>>> >>
>>> >>
>>> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>> >>
>>> >> > One can find the deb/rpm packages here:
>>> >> >
>>> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>> >> >
>>> >> > And here are the corresponding docker images based off of Ubuntu
>>> 14.04:
>>> >> > mesosphere/mesos:1.0.0-rc4
>>> >> > mesosphere/mesos-master:1.0.0-rc4
>>> >> > mesosphere/mesos-slave:1.0.0-rc4
>>> >> >
>>> >> > Kapil
>>> >> >
>>> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Best Regards,
>>> >> Haosdent Huang
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
-1
We tested it in our testing environment but webUI redirect didn't work. We filed: https://issues.apache.org/jira/browse/MESOS-5911 <https://issues.apache.org/jira/browse/MESOS-5911>
Given that webUI is the portal for Mesos clusters I feel that we should at least have a basic fix (more context in the JIRA) before release 1.0. Thoughts?
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zhitaoli.cs@gmail.com <ma...@gmail.com>> wrote:
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test suite (on its master) is that scheduler previously expected GPU resource will not receive offers without new `GPU_RESOURCES` capability even it's the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't consider this is a blocker to me, but it might be surprising to people already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bmahler@apache.org <ma...@apache.org>> wrote:
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <greg@mesosphere.io <ma...@mesosphere.io>> wrote:
>
> > +1 (non-binding)
> >
> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> > failure: ExamplesTest.PythonFramework fails for me the first time it's
> > executed as part of the whole test suite, and then succeeds on subsequent
> > executions. I'm investigating further, and will file a ticket if necessary.
> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >
> > Cheers,
> > Greg
> >
> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <haosdent@gmail.com <ma...@gmail.com>> wrote:
> >
> >> +1
> >>
> >> * make check in CentOS 7.2
> >> * make check in Ubuntu 14.04
> >> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>
> >>
> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <kapil@mesosphere.io <ma...@mesosphere.io>> wrote:
> >>
> >> > One can find the deb/rpm packages here:
> >> >
> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4 <http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4>
> >> >
> >> > And here are the corresponding docker images based off of Ubuntu 14.04:
> >> > mesosphere/mesos:1.0.0-rc4
> >> > mesosphere/mesos-master:1.0.0-rc4
> >> > mesosphere/mesos-slave:1.0.0-rc4
> >> >
> >> > Kapil
> >> >
> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <vinodkone@apache.org <ma...@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 <http://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 <http://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 <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 <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 <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 <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 <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 <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 <https://repository.apache.org/content/repositories/orgapachemesos-1153>
> >> > >
> >> > >
> >> > > Please vote on releasing this package as Apache Mesos 1.0.0!
> >> > >
> >> > >
> >> > > [ ] +1 Release this package as Apache Mesos 1.0.0
> >> > >
> >> > > [ ] -1 Do not release this package because ...
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Haosdent Huang
> >>
> >
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Yan Xu <xu...@apple.com>.
-1
We tested it in our testing environment but webUI redirect didn't work. We filed: https://issues.apache.org/jira/browse/MESOS-5911 <https://issues.apache.org/jira/browse/MESOS-5911>
Given that webUI is the portal for Mesos clusters I feel that we should at least have a basic fix (more context in the JIRA) before release 1.0. Thoughts?
> On Jul 26, 2016, at 2:52 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> +1 (binding)
>
> OpenSUSE Tumbleweed:
> ./configure --disable-java --disable-python && make check
>
> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zhitaoli.cs@gmail.com <ma...@gmail.com>> wrote:
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test suite (on its master) is that scheduler previously expected GPU resource will not receive offers without new `GPU_RESOURCES` capability even it's the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't consider this is a blocker to me, but it might be surprising to people already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bmahler@apache.org <ma...@apache.org>> wrote:
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <greg@mesosphere.io <ma...@mesosphere.io>> wrote:
>
> > +1 (non-binding)
> >
> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> > failure: ExamplesTest.PythonFramework fails for me the first time it's
> > executed as part of the whole test suite, and then succeeds on subsequent
> > executions. I'm investigating further, and will file a ticket if necessary.
> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >
> > Cheers,
> > Greg
> >
> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <haosdent@gmail.com <ma...@gmail.com>> wrote:
> >
> >> +1
> >>
> >> * make check in CentOS 7.2
> >> * make check in Ubuntu 14.04
> >> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>
> >>
> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <kapil@mesosphere.io <ma...@mesosphere.io>> wrote:
> >>
> >> > One can find the deb/rpm packages here:
> >> >
> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4 <http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4>
> >> >
> >> > And here are the corresponding docker images based off of Ubuntu 14.04:
> >> > mesosphere/mesos:1.0.0-rc4
> >> > mesosphere/mesos-master:1.0.0-rc4
> >> > mesosphere/mesos-slave:1.0.0-rc4
> >> >
> >> > Kapil
> >> >
> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <vinodkone@apache.org <ma...@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 <http://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 <http://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 <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 <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 <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 <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 <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 <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 <https://repository.apache.org/content/repositories/orgapachemesos-1153>
> >> > >
> >> > >
> >> > > Please vote on releasing this package as Apache Mesos 1.0.0!
> >> > >
> >> > >
> >> > > [ ] +1 Release this package as Apache Mesos 1.0.0
> >> > >
> >> > > [ ] -1 Do not release this package because ...
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Haosdent Huang
> >>
> >
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
+1 (binding)
OpenSUSE Tumbleweed:
./configure --disable-java --disable-python && make check
On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test
> suite (on its master) is that scheduler previously expected GPU resource
> will not receive offers without new `GPU_RESOURCES` capability even it's
> the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't
> consider this is a blocker to me, but it might be surprising to people
> already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> > +1 (non-binding)
>> >
>> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>> test
>> > failure: ExamplesTest.PythonFramework fails for me the first time it's
>> > executed as part of the whole test suite, and then succeeds on
>> subsequent
>> > executions. I'm investigating further, and will file a ticket if
>> necessary.
>> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>> >
>> > Cheers,
>> > Greg
>> >
>> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>> >
>> >> +1
>> >>
>> >> * make check in CentOS 7.2
>> >> * make check in Ubuntu 14.04
>> >> * test upgrade from 0.28.2 to 1.0.0-rc4
>> >>
>> >>
>> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >>
>> >> > One can find the deb/rpm packages here:
>> >> >
>> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>> >> >
>> >> > And here are the corresponding docker images based off of Ubuntu
>> 14.04:
>> >> > mesosphere/mesos:1.0.0-rc4
>> >> > mesosphere/mesos-master:1.0.0-rc4
>> >> > mesosphere/mesos-slave:1.0.0-rc4
>> >> >
>> >> > Kapil
>> >> >
>> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Haosdent Huang
>> >>
>> >
>> >
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
+1 (binding)
OpenSUSE Tumbleweed:
./configure --disable-java --disable-python && make check
On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zh...@gmail.com> wrote:
> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test
> suite (on its master) is that scheduler previously expected GPU resource
> will not receive offers without new `GPU_RESOURCES` capability even it's
> the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't
> consider this is a blocker to me, but it might be surprising to people
> already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>>
>> > +1 (non-binding)
>> >
>> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>> test
>> > failure: ExamplesTest.PythonFramework fails for me the first time it's
>> > executed as part of the whole test suite, and then succeeds on
>> subsequent
>> > executions. I'm investigating further, and will file a ticket if
>> necessary.
>> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>> >
>> > Cheers,
>> > Greg
>> >
>> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>> >
>> >> +1
>> >>
>> >> * make check in CentOS 7.2
>> >> * make check in Ubuntu 14.04
>> >> * test upgrade from 0.28.2 to 1.0.0-rc4
>> >>
>> >>
>> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >>
>> >> > One can find the deb/rpm packages here:
>> >> >
>> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>> >> >
>> >> > And here are the corresponding docker images based off of Ubuntu
>> 14.04:
>> >> > mesosphere/mesos:1.0.0-rc4
>> >> > mesosphere/mesos-master:1.0.0-rc4
>> >> > mesosphere/mesos-slave:1.0.0-rc4
>> >> >
>> >> > Kapil
>> >> >
>> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Haosdent Huang
>> >>
>> >
>> >
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Zhitao Li <zh...@gmail.com>.
Also tested:
make check passes on OS X
One thing I found when testing RC4 debian with Aurora integration test
suite (on its master) is that scheduler previously expected GPU resource
will not receive offers without new `GPU_RESOURCES` capability even it's
the only scheduler.
Given that GPU support is not technically released until 1.0, I don't
consider this is a blocker to me, but it might be surprising to people
already testing GPU support.
On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
wrote:
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
> > +1 (non-binding)
> >
> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> > failure: ExamplesTest.PythonFramework fails for me the first time it's
> > executed as part of the whole test suite, and then succeeds on subsequent
> > executions. I'm investigating further, and will file a ticket if
> necessary.
> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >
> > Cheers,
> > Greg
> >
> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> >
> >> +1
> >>
> >> * make check in CentOS 7.2
> >> * make check in Ubuntu 14.04
> >> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>
> >>
> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >>
> >> > One can find the deb/rpm packages here:
> >> >
> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >> >
> >> > And here are the corresponding docker images based off of Ubuntu
> 14.04:
> >> > mesosphere/mesos:1.0.0-rc4
> >> > mesosphere/mesos-master:1.0.0-rc4
> >> > mesosphere/mesos-slave:1.0.0-rc4
> >> >
> >> > Kapil
> >> >
> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Haosdent Huang
> >>
> >
> >
>
--
Cheers,
Zhitao Li
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Zhitao Li <zh...@gmail.com>.
Also tested:
make check passes on OS X
One thing I found when testing RC4 debian with Aurora integration test
suite (on its master) is that scheduler previously expected GPU resource
will not receive offers without new `GPU_RESOURCES` capability even it's
the only scheduler.
Given that GPU support is not technically released until 1.0, I don't
consider this is a blocker to me, but it might be surprising to people
already testing GPU support.
On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bm...@apache.org>
wrote:
> +1 (binding)
>
> OS X 10.11.6
> ./configure --disable-python --disable-java
> make check
>
> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
> > +1 (non-binding)
> >
> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> > failure: ExamplesTest.PythonFramework fails for me the first time it's
> > executed as part of the whole test suite, and then succeeds on subsequent
> > executions. I'm investigating further, and will file a ticket if
> necessary.
> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
> >
> > Cheers,
> > Greg
> >
> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> >
> >> +1
> >>
> >> * make check in CentOS 7.2
> >> * make check in Ubuntu 14.04
> >> * test upgrade from 0.28.2 to 1.0.0-rc4
> >>
> >>
> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >>
> >> > One can find the deb/rpm packages here:
> >> >
> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >> >
> >> > And here are the corresponding docker images based off of Ubuntu
> 14.04:
> >> > mesosphere/mesos:1.0.0-rc4
> >> > mesosphere/mesos-master:1.0.0-rc4
> >> > mesosphere/mesos-slave:1.0.0-rc4
> >> >
> >> > Kapil
> >> >
> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Haosdent Huang
> >>
> >
> >
>
--
Cheers,
Zhitao Li
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Benjamin Mahler <bm...@apache.org>.
+1 (binding)
OS X 10.11.6
./configure --disable-python --disable-java
make check
On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
> +1 (non-binding)
>
> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> failure: ExamplesTest.PythonFramework fails for me the first time it's
> executed as part of the whole test suite, and then succeeds on subsequent
> executions. I'm investigating further, and will file a ticket if necessary.
> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>
> Cheers,
> Greg
>
> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> > One can find the deb/rpm packages here:
>> >
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>> >
>> > And here are the corresponding docker images based off of Ubuntu 14.04:
>> > mesosphere/mesos:1.0.0-rc4
>> > mesosphere/mesos-master:1.0.0-rc4
>> > mesosphere/mesos-slave:1.0.0-rc4
>> >
>> > Kapil
>> >
>> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> > >
>> >
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Benjamin Mahler <bm...@apache.org>.
+1 (binding)
OS X 10.11.6
./configure --disable-python --disable-java
make check
On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <gr...@mesosphere.io> wrote:
> +1 (non-binding)
>
> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
> failure: ExamplesTest.PythonFramework fails for me the first time it's
> executed as part of the whole test suite, and then succeeds on subsequent
> executions. I'm investigating further, and will file a ticket if necessary.
> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>
> Cheers,
> Greg
>
> On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
>
>> +1
>>
>> * make check in CentOS 7.2
>> * make check in Ubuntu 14.04
>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>
>>
>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> > One can find the deb/rpm packages here:
>> >
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>> >
>> > And here are the corresponding docker images based off of Ubuntu 14.04:
>> > mesosphere/mesos:1.0.0-rc4
>> > mesosphere/mesos-master:1.0.0-rc4
>> > mesosphere/mesos-slave:1.0.0-rc4
>> >
>> > Kapil
>> >
>> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>> > >
>> >
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Greg Mann <gr...@mesosphere.io>.
+1 (non-binding)
* Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
failure: ExamplesTest.PythonFramework fails for me the first time it's
executed as part of the whole test suite, and then succeeds on subsequent
executions. I'm investigating further, and will file a ticket if necessary.
* Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
Cheers,
Greg
On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > One can find the deb/rpm packages here:
> >
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >
> > And here are the corresponding docker images based off of Ubuntu 14.04:
> > mesosphere/mesos:1.0.0-rc4
> > mesosphere/mesos-master:1.0.0-rc4
> > mesosphere/mesos-slave:1.0.0-rc4
> >
> > Kapil
> >
> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Greg Mann <gr...@mesosphere.io>.
+1 (non-binding)
* Ran `sudo make distcheck` successfully on CentOS 7.1 with only one test
failure: ExamplesTest.PythonFramework fails for me the first time it's
executed as part of the whole test suite, and then succeeds on subsequent
executions. I'm investigating further, and will file a ticket if necessary.
* Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
Cheers,
Greg
On Tue, Jul 26, 2016 at 1:58 AM, haosdent <ha...@gmail.com> wrote:
> +1
>
> * make check in CentOS 7.2
> * make check in Ubuntu 14.04
> * test upgrade from 0.28.2 to 1.0.0-rc4
>
>
> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > One can find the deb/rpm packages here:
> >
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
> >
> > And here are the corresponding docker images based off of Ubuntu 14.04:
> > mesosphere/mesos:1.0.0-rc4
> > mesosphere/mesos-master:1.0.0-rc4
> > mesosphere/mesos-slave:1.0.0-rc4
> >
> > Kapil
> >
> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
+1
* make check in CentOS 7.2
* make check in Ubuntu 14.04
* test upgrade from 0.28.2 to 1.0.0-rc4
On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
> One can find the deb/rpm packages here:
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>
> And here are the corresponding docker images based off of Ubuntu 14.04:
> mesosphere/mesos:1.0.0-rc4
> mesosphere/mesos-master:1.0.0-rc4
> mesosphere/mesos-slave:1.0.0-rc4
>
> Kapil
>
> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by haosdent <ha...@gmail.com>.
+1
* make check in CentOS 7.2
* make check in Ubuntu 14.04
* test upgrade from 0.28.2 to 1.0.0-rc4
On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io> wrote:
> One can find the deb/rpm packages here:
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>
> And here are the corresponding docker images based off of Ubuntu 14.04:
> mesosphere/mesos:1.0.0-rc4
> mesosphere/mesos-master:1.0.0-rc4
> mesosphere/mesos-slave:1.0.0-rc4
>
> Kapil
>
> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
> >
>
--
Best Regards,
Haosdent Huang
Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Posted by Kapil Arya <ka...@mesosphere.io>.
One can find the deb/rpm packages here:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0-rc4
mesosphere/mesos-master:1.0.0-rc4
mesosphere/mesos-slave:1.0.0-rc4
Kapil
On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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 Kapil Arya <ka...@mesosphere.io>.
One can find the deb/rpm packages here:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0-rc4
mesosphere/mesos-master:1.0.0-rc4
mesosphere/mesos-slave:1.0.0-rc4
Kapil
On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <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,
>