[VOTE] Release Apache Mesos 1.0.0 (rc2)

[Vinod Kone <vi...@apache.org>]

Hi all,


Please vote on releasing the following candidate as Apache Mesos 1.0.0.


1.0.0 includes the following:

--------------------------------------------------------------------------------

  * Scheduler and Executor v1 HTTP APIs are now considered stable.





  * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
These

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


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


    `docs/operator-http-api.md` for details.





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


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

    docs/mesos-containerizer.md for more details.





  * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
added a

    new isolator 'docker/volume' which allows users to use external volumes
in

    Mesos containerizer. Currently, the isolator interacts with the Docker


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

    plugin API, most of the Docker volume plugins are supported.





  * [MESOS-4641] - **Experimental** A new network isolator, the


    `network/cni` isolator, has been introduced in the
`MesosContainerizer`. The

    `network/cni` isolator implements the Container Network Interface (CNI)


    specification proposed by CoreOS.  With CNI the `network/cni` isolator
is

    able to allocate a network namespace to Mesos containers and attach the


    container to different types of IP networks by invoking network drivers


    called CNI plugins.





  * [MESOS-2948, MESOS-5403] - The authorizer interface has been refactored
in

    order to decouple the ACLs definition language from the interface.


    It additionally includes the option of retrieving `ObjectApprover`. An


    `ObjectApprover` can be used to synchronously check authorizations for
a

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

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


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




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

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

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

    be allowed.

    NOTE: This is a semantic change for authorizer modules.





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

    filtering enables operators to restrict what part of the cluster state
a

    user is authorized to see.


    Consider for example the `/state` master endpoint: an operator can now


    authorize users to only see a subset of the running frameworks, tasks,
or

    executors. The following endpoints support HTTP endpoint filtering:


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


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


    'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
'GET_TASKS'.




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

    because machine failures or forcible terminations may occur. Currently,
the

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

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

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


    responsibility to enforce kill policies. For executor-less
command-based

    tasks, the kill is performed via sending a signal to the task process:


    SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
docker

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

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




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

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

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

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

    it is the executor's responsibility to honor the
'Event.kill.kill_policy'

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

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


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

    the agent launches the HTTP API based command executor.





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

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


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

    specified here before forcibly destroying the container. The executor
must

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

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


    terminations may occur. Together with kill policies this gives
frameworks

    flexibility around how to clean up tasks and executors.




  * [MESOS-3094] - **Experimental** support for launching mesos tasks on


    Windows. Note that there are no isolation guarantees provided yet.





  * [MESOS-4090] - The `mesos.native` python module has been split into
two,

    `mesos.executor` and `mesos.scheduler`. This change also removes


    un-necessary 3rd party dependencies from `mesos.executor` and


    `mesos.scheduler`. `mesos.native` still exists, combining both modules
for

    backwards compatibility with existing code.





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

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


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

    the logging output has been updated to use the term 'agent' now. Flags,


    binaries and scripts with 'slave' keyword have been deprecated (see


    "Deprecations section below").





  * [MESOS-4312] - **Experimental** support for building and running mesos
on

    IBM PowerPC platform.





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

    via the new '/weights' endpoint on the master.





  * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the


    Mesos "unified" containerizer. This support includes running containers


    with and without filesystem isolation (i.e. running both imageless


    containers as well as containers using a docker image). Frameworks must


    opt-in to receiving GPU resources via the GPU_RESOURCES framework


    capability (see the scarce resource problem in MESOS-5377). We support


    'nvidia-docker'-style docker containers by injecting a volume that


    contains the Nvidia libraries / binaries when the docker image has


    the 'com.nvidia.volumes.needed' label. Support for the docker


    containerizer will come in a future release.





  * [MESOS-5724] - SSL certificate validation allows for additional IP
address

    subject alternative name extension verification.





The CHANGELOG for the release is available at:

https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2

--------------------------------------------------------------------------------


The candidate for Mesos 1.0.0 release is available at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz


The tag to be voted on is 1.0.0-rc2:

https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2


The MD5 checksum of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5


The signature of the tarball can be found at:

https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc


The PGP key used to sign the release is here:

https://dist.apache.org/repos/dist/release/mesos/KEYS


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

https://repository.apache.org/content/repositories/orgapachemesos-1149


Please vote on releasing this package as Apache Mesos 1.0.0!


The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
majority of at least 3 +1 PMC votes are cast.


[ ] +1 Release this package as Apache Mesos 1.0.0

[ ] -1 Do not release this package because ...


Thanks,

Vinod

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Vinod Kone <vi...@apache.org>]

This vote is cancelled. I'll cut RC3 this week after the blockers are
resolved.

On Sat, Jul 16, 2016 at 3:47 PM, Avinash Sridharan <av...@mesosphere.io>
wrote:

> Given MESOS-5806 <https://issues.apache.org/jira/browse/MESOS-5806> and
> the
> fixes landed by Jie and Qian, I would give a
> -1 (non-binding)
>
> I think MESOS-5806 is critical for running containers (with images) on the
> host network, which seems like an important use-case to cover. Hence, would
> definitely want this fixed in 1.0 .
>
> On Sat, Jul 16, 2016 at 12:41 AM, Jörg Schad <jo...@mesosphere.io> wrote:
>
> > +1 non-binding
> >
> > {OSX, Ubuntu 16)
> > - sudo make check
> > - upgrade script
> >
> > Short question: until when is this vote open?
> >
> >
> > On Sat, Jul 16, 2016 at 7:40 AM, tommy xiao <xi...@gmail.com> wrote:
> > >
> > >> +1
> > >>
> > >> Tested on Fedora release 23 (Twenty Three)
> > >>
> > >> - make check
> > >> - 1.0.0-rc2
> > >>
> > >> 2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:
> > >>
> > >>> +1
> > >>>
> > >>> Tested on CentOS 7.
> > >>>
> > >>> - sudo make check
> > >>> - upgrade from 0.28.2 to 1.0.0-rc2
> > >>>
> > >>> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <alex@mesosphere.com
> >
> > >>> wrote:
> > >>>
> > >>>> Haosdent investigated the issue, and it seems that health checks do
> > >>>> work for docker executor. Hence I retract my negative vote.
> > >>>>
> > >>>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <
> alex@mesosphere.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> -1 (binding): MESOS-5848
> > >>>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on
> > the
> > >>>>> way.
> > >>>>>
> > >>>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> +1 (nonbinding)
> > >>>>>>
> > >>>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
> > >>>>>> downgrade on a small test cluster for both master and slave.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <kapil@mesosphere.io
> >
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> None of the stable builds have SSL yet. The first SSL-enabled
> > stable
> > >>>>>>> build
> > >>>>>>> will be 1.0.0. Sorry for the confusion.
> > >>>>>>>
> > >>>>>>> Kapil
> > >>>>>>>
> > >>>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <
> zhitaoli.cs@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> > Hi Kapil,
> > >>>>>>> >
> > >>>>>>> > Do you mean that the stable builds from
> > >>>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
> > >>>>>>> configuration?
> > >>>>>>> >
> > >>>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <
> > kapil@mesosphere.io>
> > >>>>>>> wrote:
> > >>>>>>> >
> > >>>>>>> >> The binary rpm/deb packages can be found here:
> > >>>>>>> >>
> > >>>>>>>
> > http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
> > >>>>>>> >> .
> > >>>>>>> >>
> > >>>>>>> >> Please note that starting with the 1.0.0 release (including
> RCs
> > >>>>>>> and
> > >>>>>>> >> recent nightly builds), Mesos is configured with SSL and
> > 3rdparty
> > >>>>>>> >> module dependency installation. Here is the configure command
> > >>>>>>> line:
> > >>>>>>> >>     ./configure --enable-libevent --enable-ssl
> > >>>>>>> >> --enable-install-module-dependencies
> > >>>>>>> >>
> > >>>>>>> >> As always, the stable builds are available at:
> > >>>>>>> >>     http://open.mesosphere.com/downloads/mesos
> > >>>>>>> >>
> > >>>>>>> >> The instructions for nightly builds are available at:
> > >>>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
> > >>>>>>> >>
> > >>>>>>> >> Best,
> > >>>>>>> >> Kapil
> > >>>>>>> >>
> > >>>>>>> >>
> > >>>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <
> > vinodkone@apache.org>
> > >>>>>>> wrote:
> > >>>>>>> >> >
> > >>>>>>> >> > Hi all,
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > Please vote on releasing the following candidate as Apache
> > >>>>>>> Mesos 1.0.0.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > 1.0.0 includes the following:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> --------------------------------------------------------------------------------
> > >>>>>>> >> >
> > >>>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered
> > >>>>>>> stable.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master
> and
> > >>>>>>> Agent
> > >>>>>>> >> APIs.
> > >>>>>>> >> > These
> > >>>>>>> >> >
> > >>>>>>> >> >     APIs let operators and services (monitoring, load
> > >>>>>>> balancers) send
> > >>>>>>> >> HTTP
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     `docs/operator-http-api.md` for details.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new
> > `disk/xfs'
> > >>>>>>> >> isolator
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     has been added to isolate disk resources more
> efficiently.
> > >>>>>>> Please
> > >>>>>>> >> refer
> > >>>>>>> >> > to
> > >>>>>>> >> >
> > >>>>>>> >> >     docs/mesos-containerizer.md for more details.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker
> volume
> > >>>>>>> plugin. We
> > >>>>>>> >> > added a
> > >>>>>>> >> >
> > >>>>>>> >> >     new isolator 'docker/volume' which allows users to use
> > >>>>>>> external
> > >>>>>>> >> volumes
> > >>>>>>> >> > in
> > >>>>>>> >> >
> > >>>>>>> >> >     Mesos containerizer. Currently, the isolator interacts
> > with
> > >>>>>>> the
> > >>>>>>> >> Docker
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking
> > >>>>>>> the Docker
> > >>>>>>> >> > volume
> > >>>>>>> >> >
> > >>>>>>> >> >     plugin API, most of the Docker volume plugins are
> > supported.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator,
> > the
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     `network/cni` isolator, has been introduced in the
> > >>>>>>> >> > `MesosContainerizer`. The
> > >>>>>>> >> >
> > >>>>>>> >> >     `network/cni` isolator implements the Container Network
> > >>>>>>> Interface
> > >>>>>>> >> (CNI)
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     specification proposed by CoreOS.  With CNI the
> > >>>>>>> `network/cni`
> > >>>>>>> >> isolator
> > >>>>>>> >> > is
> > >>>>>>> >> >
> > >>>>>>> >> >     able to allocate a network namespace to Mesos containers
> > >>>>>>> and attach
> > >>>>>>> >> the
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     container to different types of IP networks by invoking
> > >>>>>>> network
> > >>>>>>> >> drivers
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     called CNI plugins.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has
> > been
> > >>>>>>> >> refactored
> > >>>>>>> >> > in
> > >>>>>>> >> >
> > >>>>>>> >> >     order to decouple the ACLs definition language from the
> > >>>>>>> interface.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     It additionally includes the option of retrieving
> > >>>>>>> `ObjectApprover`.
> > >>>>>>> >> An
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     `ObjectApprover` can be used to synchronously check
> > >>>>>>> authorizations
> > >>>>>>> >> for
> > >>>>>>> >> > a
> > >>>>>>> >> >
> > >>>>>>> >> >     given object and is hence useful when authorizing a
> large
> > >>>>>>> number of
> > >>>>>>> >> > objects
> > >>>>>>> >> >
> > >>>>>>> >> >     and/or large objects (which need to be copied using
> > request
> > >>>>>>> based
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     authorization). NOTE: This is a **breaking change** for
> > >>>>>>> authorizer
> > >>>>>>> >> > modules.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
> > >>>>>>> >> > authorization::Request
> > >>>>>>> >> >
> > >>>>>>> >> >     have been changed from required to optional. If either
> of
> > >>>>>>> these
> > >>>>>>> >> fields
> > >>>>>>> >> > is
> > >>>>>>> >> >
> > >>>>>>> >> >     not set, the request should only be authorized if any
> > >>>>>>> subject/object
> > >>>>>>> >> > should
> > >>>>>>> >> >
> > >>>>>>> >> >     be allowed.
> > >>>>>>> >> >
> > >>>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization
> based
> > >>>>>>> HTTP
> > >>>>>>> >> > endpoint
> > >>>>>>> >> >
> > >>>>>>> >> >     filtering enables operators to restrict what part of the
> > >>>>>>> cluster
> > >>>>>>> >> state
> > >>>>>>> >> > a
> > >>>>>>> >> >
> > >>>>>>> >> >     user is authorized to see.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     Consider for example the `/state` master endpoint: an
> > >>>>>>> operator can
> > >>>>>>> >> now
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     authorize users to only see a subset of the running
> > >>>>>>> frameworks,
> > >>>>>>> >> tasks,
> > >>>>>>> >> > or
> > >>>>>>> >> >
> > >>>>>>> >> >     executors. The following endpoints support HTTP endpoint
> > >>>>>>> filtering:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     '/state', '/state-summary', '/tasks',
> > >>>>>>> '/frameworks','/weights',
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     and '/roles'. Additonally the following v1 API calls
> > support
> > >>>>>>> >> filtering:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE',
> > and
> > >>>>>>> >> > 'GET_TASKS'.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They
> > are
> > >>>>>>> >> > best-effort,
> > >>>>>>> >> >
> > >>>>>>> >> >     because machine failures or forcible terminations may
> > occur.
> > >>>>>>> >> Currently,
> > >>>>>>> >> > the
> > >>>>>>> >> >
> > >>>>>>> >> >     only available kill policy is how long to wait between
> > >>>>>>> graceful and
> > >>>>>>> >> > forcible
> > >>>>>>> >> >
> > >>>>>>> >> >     task kill. In the future, more policies may be available
> > >>>>>>> (e.g.
> > >>>>>>> >> hitting
> > >>>>>>> >> > an
> > >>>>>>> >> >
> > >>>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is
> > the
> > >>>>>>> >> executor's
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     responsibility to enforce kill policies. For
> executor-less
> > >>>>>>> >> > command-based
> > >>>>>>> >> >
> > >>>>>>> >> >     tasks, the kill is performed via sending a signal to the
> > >>>>>>> task
> > >>>>>>> >> process:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the
> forcible
> > >>>>>>> kill. For
> > >>>>>>> >> > docker
> > >>>>>>> >> >
> > >>>>>>> >> >     executor-less tasks the grace period is passed to
> 'docker
> > >>>>>>> stop
> > >>>>>>> >> --time'.
> > >>>>>>> >> > This
> > >>>>>>> >> >
> > >>>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is
> > now
> > >>>>>>> >> > deprecated.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4908] - The task kill policy defined within
> > >>>>>>> 'TaskInfo' can
> > >>>>>>> >> now
> > >>>>>>> >> > be
> > >>>>>>> >> >
> > >>>>>>> >> >     overridden when the scheduler kills the task. This can
> be
> > >>>>>>> used by
> > >>>>>>> >> > schedulers
> > >>>>>>> >> >
> > >>>>>>> >> >     to forcefully kill a task which is already being killed,
> > >>>>>>> e.g. if
> > >>>>>>> >> > something
> > >>>>>>> >> >
> > >>>>>>> >> >     went wrong during a graceful kill and a forcible kill is
> > >>>>>>> desired.
> > >>>>>>> >> Note
> > >>>>>>> >> > that
> > >>>>>>> >> >
> > >>>>>>> >> >     it is the executor's responsibility to honor the
> > >>>>>>> >> > 'Event.kill.kill_policy'
> > >>>>>>> >> >
> > >>>>>>> >> >     field and override the task's kill policy and kill
> policy
> > >>>>>>> from a
> > >>>>>>> >> > previous
> > >>>>>>> >> >
> > >>>>>>> >> >     kill task request. To use this feature, schedulers and
> > >>>>>>> executors
> > >>>>>>> >> must
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     support HTTP API; use the '--http_command_executor'
> agent
> > >>>>>>> flag to
> > >>>>>>> >> > ensure
> > >>>>>>> >> >
> > >>>>>>> >> >     the agent launches the HTTP API based command executor.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can
> now
> > be
> > >>>>>>> >> configured
> > >>>>>>> >> > in
> > >>>>>>> >> >
> > >>>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When
> > >>>>>>> shutting down
> > >>>>>>> >> an
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     executor the agent will wait in a best-effort manner for
> > >>>>>>> the grace
> > >>>>>>> >> > period
> > >>>>>>> >> >
> > >>>>>>> >> >     specified here before forcibly destroying the container.
> > The
> > >>>>>>> >> executor
> > >>>>>>> >> > must
> > >>>>>>> >> >
> > >>>>>>> >> >     not assume that it will always be allotted the full
> grace
> > >>>>>>> period, as
> > >>>>>>> >> > the
> > >>>>>>> >> >
> > >>>>>>> >> >     agent may decide to allot a shorter period and failures
> /
> > >>>>>>> forcible
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     terminations may occur. Together with kill policies this
> > >>>>>>> gives
> > >>>>>>> >> > frameworks
> > >>>>>>> >> >
> > >>>>>>> >> >     flexibility around how to clean up tasks and executors.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching
> > mesos
> > >>>>>>> tasks on
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     Windows. Note that there are no isolation guarantees
> > >>>>>>> provided yet.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
> > >>>>>>> split into
> > >>>>>>> >> > two,
> > >>>>>>> >> >
> > >>>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
> > >>>>>>> removes
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     un-necessary 3rd party dependencies from
> `mesos.executor`
> > >>>>>>> and
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists,
> combining
> > >>>>>>> both
> > >>>>>>> >> modules
> > >>>>>>> >> > for
> > >>>>>>> >> >
> > >>>>>>> >> >     backwards compatibility with existing code.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
> > >>>>>>> complete. To
> > >>>>>>> >> > support
> > >>>>>>> >> >
> > >>>>>>> >> >     the rename, new duplicate flags (e.g.,
> > >>>>>>> --agent_reregister_timeout),
> > >>>>>>> >> new
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links
> have
> > >>>>>>> been
> > >>>>>>> >> added.
> > >>>>>>> >> > All
> > >>>>>>> >> >
> > >>>>>>> >> >     the logging output has been updated to use the term
> > 'agent'
> > >>>>>>> now.
> > >>>>>>> >> Flags,
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     binaries and scripts with 'slave' keyword have been
> > >>>>>>> deprecated (see
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     "Deprecations section below").
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
> > >>>>>>> running
> > >>>>>>> >> mesos
> > >>>>>>> >> > on
> > >>>>>>> >> >
> > >>>>>>> >> >     IBM PowerPC platform.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
> > >>>>>>> configured
> > >>>>>>> >> > dynamically
> > >>>>>>> >> >
> > >>>>>>> >> >     via the new '/weights' endpoint on the master.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a
> resource
> > >>>>>>> in the
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     Mesos "unified" containerizer. This support includes
> > running
> > >>>>>>> >> containers
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     with and without filesystem isolation (i.e. running both
> > >>>>>>> imageless
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     containers as well as containers using a docker image).
> > >>>>>>> Frameworks
> > >>>>>>> >> must
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
> > >>>>>>> framework
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     capability (see the scarce resource problem in
> > MESOS-5377).
> > >>>>>>> We
> > >>>>>>> >> support
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     'nvidia-docker'-style docker containers by injecting a
> > >>>>>>> volume that
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     contains the Nvidia libraries / binaries when the docker
> > >>>>>>> image has
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the
> > >>>>>>> docker
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >     containerizer will come in a future release.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
> > >>>>>>> additional IP
> > >>>>>>> >> > address
> > >>>>>>> >> >
> > >>>>>>> >> >     subject alternative name extension verification.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The CHANGELOG for the release is available at:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> --------------------------------------------------------------------------------
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The tag to be voted on is 1.0.0-rc2:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The MD5 checksum of the tarball can be found at:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The signature of the tarball can be found at:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >>
> > >>>>>>>
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The PGP key used to sign the release is here:
> > >>>>>>> >> >
> > >>>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The JAR is up in Maven in a staging repository here:
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>>
> > https://repository.apache.org/content/repositories/orgapachemesos-1149
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and
> passes
> > >>>>>>> if a
> > >>>>>>> >> > majority of at least 3 +1 PMC votes are cast.
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
> > >>>>>>> >> >
> > >>>>>>> >> > [ ] -1 Do not release this package because ...
> > >>>>>>> >> >
> > >>>>>>> >> >
> > >>>>>>> >> > Thanks,
> > >>>>>>> >> >
> > >>>>>>> >> > Vinod
> > >>>>>>> >>
> > >>>>>>> >
> > >>>>>>> >
> > >>>>>>> >
> > >>>>>>> > --
> > >>>>>>> > Cheers,
> > >>>>>>> >
> > >>>>>>> > Zhitao Li
> > >>>>>>> >
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Cheers,
> > >>>>>>
> > >>>>>> Zhitao Li
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Best Regards,
> > >>> Haosdent Huang
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Deshi Xiao
> > >> Twitter: xds2000
> > >> E-mail: xiaods(AT)gmail.com
> > >>
> > >
> > >
> >
>
>
>
> --
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Avinash Sridharan <av...@mesosphere.io>]

Given MESOS-5806 <https://issues.apache.org/jira/browse/MESOS-5806> and the
fixes landed by Jie and Qian, I would give a
-1 (non-binding)

I think MESOS-5806 is critical for running containers (with images) on the
host network, which seems like an important use-case to cover. Hence, would
definitely want this fixed in 1.0 .

On Sat, Jul 16, 2016 at 12:41 AM, Jörg Schad <jo...@mesosphere.io> wrote:

> +1 non-binding
>
> {OSX, Ubuntu 16)
> - sudo make check
> - upgrade script
>
> Short question: until when is this vote open?
>
>
> On Sat, Jul 16, 2016 at 7:40 AM, tommy xiao <xi...@gmail.com> wrote:
> >
> >> +1
> >>
> >> Tested on Fedora release 23 (Twenty Three)
> >>
> >> - make check
> >> - 1.0.0-rc2
> >>
> >> 2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:
> >>
> >>> +1
> >>>
> >>> Tested on CentOS 7.
> >>>
> >>> - sudo make check
> >>> - upgrade from 0.28.2 to 1.0.0-rc2
> >>>
> >>> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com>
> >>> wrote:
> >>>
> >>>> Haosdent investigated the issue, and it seems that health checks do
> >>>> work for docker executor. Hence I retract my negative vote.
> >>>>
> >>>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <alex@mesosphere.com
> >
> >>>> wrote:
> >>>>
> >>>>> -1 (binding): MESOS-5848
> >>>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on
> the
> >>>>> way.
> >>>>>
> >>>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> +1 (nonbinding)
> >>>>>>
> >>>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
> >>>>>> downgrade on a small test cluster for both master and slave.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> None of the stable builds have SSL yet. The first SSL-enabled
> stable
> >>>>>>> build
> >>>>>>> will be 1.0.0. Sorry for the confusion.
> >>>>>>>
> >>>>>>> Kapil
> >>>>>>>
> >>>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> > Hi Kapil,
> >>>>>>> >
> >>>>>>> > Do you mean that the stable builds from
> >>>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
> >>>>>>> configuration?
> >>>>>>> >
> >>>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <
> kapil@mesosphere.io>
> >>>>>>> wrote:
> >>>>>>> >
> >>>>>>> >> The binary rpm/deb packages can be found here:
> >>>>>>> >>
> >>>>>>>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
> >>>>>>> >> .
> >>>>>>> >>
> >>>>>>> >> Please note that starting with the 1.0.0 release (including RCs
> >>>>>>> and
> >>>>>>> >> recent nightly builds), Mesos is configured with SSL and
> 3rdparty
> >>>>>>> >> module dependency installation. Here is the configure command
> >>>>>>> line:
> >>>>>>> >>     ./configure --enable-libevent --enable-ssl
> >>>>>>> >> --enable-install-module-dependencies
> >>>>>>> >>
> >>>>>>> >> As always, the stable builds are available at:
> >>>>>>> >>     http://open.mesosphere.com/downloads/mesos
> >>>>>>> >>
> >>>>>>> >> The instructions for nightly builds are available at:
> >>>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
> >>>>>>> >>
> >>>>>>> >> Best,
> >>>>>>> >> Kapil
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <
> vinodkone@apache.org>
> >>>>>>> wrote:
> >>>>>>> >> >
> >>>>>>> >> > Hi all,
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Please vote on releasing the following candidate as Apache
> >>>>>>> Mesos 1.0.0.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > 1.0.0 includes the following:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> --------------------------------------------------------------------------------
> >>>>>>> >> >
> >>>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered
> >>>>>>> stable.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
> >>>>>>> Agent
> >>>>>>> >> APIs.
> >>>>>>> >> > These
> >>>>>>> >> >
> >>>>>>> >> >     APIs let operators and services (monitoring, load
> >>>>>>> balancers) send
> >>>>>>> >> HTTP
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `docs/operator-http-api.md` for details.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new
> `disk/xfs'
> >>>>>>> >> isolator
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     has been added to isolate disk resources more efficiently.
> >>>>>>> Please
> >>>>>>> >> refer
> >>>>>>> >> > to
> >>>>>>> >> >
> >>>>>>> >> >     docs/mesos-containerizer.md for more details.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
> >>>>>>> plugin. We
> >>>>>>> >> > added a
> >>>>>>> >> >
> >>>>>>> >> >     new isolator 'docker/volume' which allows users to use
> >>>>>>> external
> >>>>>>> >> volumes
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     Mesos containerizer. Currently, the isolator interacts
> with
> >>>>>>> the
> >>>>>>> >> Docker
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking
> >>>>>>> the Docker
> >>>>>>> >> > volume
> >>>>>>> >> >
> >>>>>>> >> >     plugin API, most of the Docker volume plugins are
> supported.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator,
> the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `network/cni` isolator, has been introduced in the
> >>>>>>> >> > `MesosContainerizer`. The
> >>>>>>> >> >
> >>>>>>> >> >     `network/cni` isolator implements the Container Network
> >>>>>>> Interface
> >>>>>>> >> (CNI)
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     specification proposed by CoreOS.  With CNI the
> >>>>>>> `network/cni`
> >>>>>>> >> isolator
> >>>>>>> >> > is
> >>>>>>> >> >
> >>>>>>> >> >     able to allocate a network namespace to Mesos containers
> >>>>>>> and attach
> >>>>>>> >> the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     container to different types of IP networks by invoking
> >>>>>>> network
> >>>>>>> >> drivers
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     called CNI plugins.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has
> been
> >>>>>>> >> refactored
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     order to decouple the ACLs definition language from the
> >>>>>>> interface.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     It additionally includes the option of retrieving
> >>>>>>> `ObjectApprover`.
> >>>>>>> >> An
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `ObjectApprover` can be used to synchronously check
> >>>>>>> authorizations
> >>>>>>> >> for
> >>>>>>> >> > a
> >>>>>>> >> >
> >>>>>>> >> >     given object and is hence useful when authorizing a large
> >>>>>>> number of
> >>>>>>> >> > objects
> >>>>>>> >> >
> >>>>>>> >> >     and/or large objects (which need to be copied using
> request
> >>>>>>> based
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     authorization). NOTE: This is a **breaking change** for
> >>>>>>> authorizer
> >>>>>>> >> > modules.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
> >>>>>>> >> > authorization::Request
> >>>>>>> >> >
> >>>>>>> >> >     have been changed from required to optional. If either of
> >>>>>>> these
> >>>>>>> >> fields
> >>>>>>> >> > is
> >>>>>>> >> >
> >>>>>>> >> >     not set, the request should only be authorized if any
> >>>>>>> subject/object
> >>>>>>> >> > should
> >>>>>>> >> >
> >>>>>>> >> >     be allowed.
> >>>>>>> >> >
> >>>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
> >>>>>>> HTTP
> >>>>>>> >> > endpoint
> >>>>>>> >> >
> >>>>>>> >> >     filtering enables operators to restrict what part of the
> >>>>>>> cluster
> >>>>>>> >> state
> >>>>>>> >> > a
> >>>>>>> >> >
> >>>>>>> >> >     user is authorized to see.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Consider for example the `/state` master endpoint: an
> >>>>>>> operator can
> >>>>>>> >> now
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     authorize users to only see a subset of the running
> >>>>>>> frameworks,
> >>>>>>> >> tasks,
> >>>>>>> >> > or
> >>>>>>> >> >
> >>>>>>> >> >     executors. The following endpoints support HTTP endpoint
> >>>>>>> filtering:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     '/state', '/state-summary', '/tasks',
> >>>>>>> '/frameworks','/weights',
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     and '/roles'. Additonally the following v1 API calls
> support
> >>>>>>> >> filtering:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE',
> and
> >>>>>>> >> > 'GET_TASKS'.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They
> are
> >>>>>>> >> > best-effort,
> >>>>>>> >> >
> >>>>>>> >> >     because machine failures or forcible terminations may
> occur.
> >>>>>>> >> Currently,
> >>>>>>> >> > the
> >>>>>>> >> >
> >>>>>>> >> >     only available kill policy is how long to wait between
> >>>>>>> graceful and
> >>>>>>> >> > forcible
> >>>>>>> >> >
> >>>>>>> >> >     task kill. In the future, more policies may be available
> >>>>>>> (e.g.
> >>>>>>> >> hitting
> >>>>>>> >> > an
> >>>>>>> >> >
> >>>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is
> the
> >>>>>>> >> executor's
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     responsibility to enforce kill policies. For executor-less
> >>>>>>> >> > command-based
> >>>>>>> >> >
> >>>>>>> >> >     tasks, the kill is performed via sending a signal to the
> >>>>>>> task
> >>>>>>> >> process:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
> >>>>>>> kill. For
> >>>>>>> >> > docker
> >>>>>>> >> >
> >>>>>>> >> >     executor-less tasks the grace period is passed to 'docker
> >>>>>>> stop
> >>>>>>> >> --time'.
> >>>>>>> >> > This
> >>>>>>> >> >
> >>>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is
> now
> >>>>>>> >> > deprecated.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4908] - The task kill policy defined within
> >>>>>>> 'TaskInfo' can
> >>>>>>> >> now
> >>>>>>> >> > be
> >>>>>>> >> >
> >>>>>>> >> >     overridden when the scheduler kills the task. This can be
> >>>>>>> used by
> >>>>>>> >> > schedulers
> >>>>>>> >> >
> >>>>>>> >> >     to forcefully kill a task which is already being killed,
> >>>>>>> e.g. if
> >>>>>>> >> > something
> >>>>>>> >> >
> >>>>>>> >> >     went wrong during a graceful kill and a forcible kill is
> >>>>>>> desired.
> >>>>>>> >> Note
> >>>>>>> >> > that
> >>>>>>> >> >
> >>>>>>> >> >     it is the executor's responsibility to honor the
> >>>>>>> >> > 'Event.kill.kill_policy'
> >>>>>>> >> >
> >>>>>>> >> >     field and override the task's kill policy and kill policy
> >>>>>>> from a
> >>>>>>> >> > previous
> >>>>>>> >> >
> >>>>>>> >> >     kill task request. To use this feature, schedulers and
> >>>>>>> executors
> >>>>>>> >> must
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
> >>>>>>> flag to
> >>>>>>> >> > ensure
> >>>>>>> >> >
> >>>>>>> >> >     the agent launches the HTTP API based command executor.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now
> be
> >>>>>>> >> configured
> >>>>>>> >> > in
> >>>>>>> >> >
> >>>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When
> >>>>>>> shutting down
> >>>>>>> >> an
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     executor the agent will wait in a best-effort manner for
> >>>>>>> the grace
> >>>>>>> >> > period
> >>>>>>> >> >
> >>>>>>> >> >     specified here before forcibly destroying the container.
> The
> >>>>>>> >> executor
> >>>>>>> >> > must
> >>>>>>> >> >
> >>>>>>> >> >     not assume that it will always be allotted the full grace
> >>>>>>> period, as
> >>>>>>> >> > the
> >>>>>>> >> >
> >>>>>>> >> >     agent may decide to allot a shorter period and failures /
> >>>>>>> forcible
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     terminations may occur. Together with kill policies this
> >>>>>>> gives
> >>>>>>> >> > frameworks
> >>>>>>> >> >
> >>>>>>> >> >     flexibility around how to clean up tasks and executors.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching
> mesos
> >>>>>>> tasks on
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Windows. Note that there are no isolation guarantees
> >>>>>>> provided yet.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
> >>>>>>> split into
> >>>>>>> >> > two,
> >>>>>>> >> >
> >>>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
> >>>>>>> removes
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor`
> >>>>>>> and
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining
> >>>>>>> both
> >>>>>>> >> modules
> >>>>>>> >> > for
> >>>>>>> >> >
> >>>>>>> >> >     backwards compatibility with existing code.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
> >>>>>>> complete. To
> >>>>>>> >> > support
> >>>>>>> >> >
> >>>>>>> >> >     the rename, new duplicate flags (e.g.,
> >>>>>>> --agent_reregister_timeout),
> >>>>>>> >> new
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have
> >>>>>>> been
> >>>>>>> >> added.
> >>>>>>> >> > All
> >>>>>>> >> >
> >>>>>>> >> >     the logging output has been updated to use the term
> 'agent'
> >>>>>>> now.
> >>>>>>> >> Flags,
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     binaries and scripts with 'slave' keyword have been
> >>>>>>> deprecated (see
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     "Deprecations section below").
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
> >>>>>>> running
> >>>>>>> >> mesos
> >>>>>>> >> > on
> >>>>>>> >> >
> >>>>>>> >> >     IBM PowerPC platform.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
> >>>>>>> configured
> >>>>>>> >> > dynamically
> >>>>>>> >> >
> >>>>>>> >> >     via the new '/weights' endpoint on the master.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource
> >>>>>>> in the
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     Mesos "unified" containerizer. This support includes
> running
> >>>>>>> >> containers
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     with and without filesystem isolation (i.e. running both
> >>>>>>> imageless
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     containers as well as containers using a docker image).
> >>>>>>> Frameworks
> >>>>>>> >> must
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
> >>>>>>> framework
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     capability (see the scarce resource problem in
> MESOS-5377).
> >>>>>>> We
> >>>>>>> >> support
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     'nvidia-docker'-style docker containers by injecting a
> >>>>>>> volume that
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     contains the Nvidia libraries / binaries when the docker
> >>>>>>> image has
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the
> >>>>>>> docker
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >     containerizer will come in a future release.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
> >>>>>>> additional IP
> >>>>>>> >> > address
> >>>>>>> >> >
> >>>>>>> >> >     subject alternative name extension verification.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The CHANGELOG for the release is available at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> --------------------------------------------------------------------------------
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The tag to be voted on is 1.0.0-rc2:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The MD5 checksum of the tarball can be found at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The signature of the tarball can be found at:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The PGP key used to sign the release is here:
> >>>>>>> >> >
> >>>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The JAR is up in Maven in a staging repository here:
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>>
> https://repository.apache.org/content/repositories/orgapachemesos-1149
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes
> >>>>>>> if a
> >>>>>>> >> > majority of at least 3 +1 PMC votes are cast.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >>>>>>> >> >
> >>>>>>> >> > [ ] -1 Do not release this package because ...
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Thanks,
> >>>>>>> >> >
> >>>>>>> >> > Vinod
> >>>>>>> >>
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > --
> >>>>>>> > Cheers,
> >>>>>>> >
> >>>>>>> > Zhitao Li
> >>>>>>> >
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Zhitao Li
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Best Regards,
> >>> Haosdent Huang
> >>>
> >>
> >>
> >>
> >> --
> >> Deshi Xiao
> >> Twitter: xds2000
> >> E-mail: xiaods(AT)gmail.com
> >>
> >
> >
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Jörg Schad <jo...@mesosphere.io>]

+1 non-binding

{OSX, Ubuntu 16)
- sudo make check
- upgrade script

Short question: until when is this vote open?


On Sat, Jul 16, 2016 at 7:40 AM, tommy xiao <xi...@gmail.com> wrote:
>
>> +1
>>
>> Tested on Fedora release 23 (Twenty Three)
>>
>> - make check
>> - 1.0.0-rc2
>>
>> 2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:
>>
>>> +1
>>>
>>> Tested on CentOS 7.
>>>
>>> - sudo make check
>>> - upgrade from 0.28.2 to 1.0.0-rc2
>>>
>>> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com>
>>> wrote:
>>>
>>>> Haosdent investigated the issue, and it seems that health checks do
>>>> work for docker executor. Hence I retract my negative vote.
>>>>
>>>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
>>>> wrote:
>>>>
>>>>> -1 (binding): MESOS-5848
>>>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>>>>> way.
>>>>>
>>>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> +1 (nonbinding)
>>>>>>
>>>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>>>>> downgrade on a small test cluster for both master and slave.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>>>>> wrote:
>>>>>>
>>>>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>>>>> build
>>>>>>> will be 1.0.0. Sorry for the confusion.
>>>>>>>
>>>>>>> Kapil
>>>>>>>
>>>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Hi Kapil,
>>>>>>> >
>>>>>>> > Do you mean that the stable builds from
>>>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>>>>> configuration?
>>>>>>> >
>>>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> >> The binary rpm/deb packages can be found here:
>>>>>>> >>
>>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>>>>> >> .
>>>>>>> >>
>>>>>>> >> Please note that starting with the 1.0.0 release (including RCs
>>>>>>> and
>>>>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>>>>> >> module dependency installation. Here is the configure command
>>>>>>> line:
>>>>>>> >>     ./configure --enable-libevent --enable-ssl
>>>>>>> >> --enable-install-module-dependencies
>>>>>>> >>
>>>>>>> >> As always, the stable builds are available at:
>>>>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>>>>> >>
>>>>>>> >> The instructions for nightly builds are available at:
>>>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>>>>> >>
>>>>>>> >> Best,
>>>>>>> >> Kapil
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>>>>> wrote:
>>>>>>> >> >
>>>>>>> >> > Hi all,
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Please vote on releasing the following candidate as Apache
>>>>>>> Mesos 1.0.0.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > 1.0.0 includes the following:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> --------------------------------------------------------------------------------
>>>>>>> >> >
>>>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered
>>>>>>> stable.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
>>>>>>> Agent
>>>>>>> >> APIs.
>>>>>>> >> > These
>>>>>>> >> >
>>>>>>> >> >     APIs let operators and services (monitoring, load
>>>>>>> balancers) send
>>>>>>> >> HTTP
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     `docs/operator-http-api.md` for details.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>>>>> >> isolator
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     has been added to isolate disk resources more efficiently.
>>>>>>> Please
>>>>>>> >> refer
>>>>>>> >> > to
>>>>>>> >> >
>>>>>>> >> >     docs/mesos-containerizer.md for more details.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>>>>> plugin. We
>>>>>>> >> > added a
>>>>>>> >> >
>>>>>>> >> >     new isolator 'docker/volume' which allows users to use
>>>>>>> external
>>>>>>> >> volumes
>>>>>>> >> > in
>>>>>>> >> >
>>>>>>> >> >     Mesos containerizer. Currently, the isolator interacts with
>>>>>>> the
>>>>>>> >> Docker
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking
>>>>>>> the Docker
>>>>>>> >> > volume
>>>>>>> >> >
>>>>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     `network/cni` isolator, has been introduced in the
>>>>>>> >> > `MesosContainerizer`. The
>>>>>>> >> >
>>>>>>> >> >     `network/cni` isolator implements the Container Network
>>>>>>> Interface
>>>>>>> >> (CNI)
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     specification proposed by CoreOS.  With CNI the
>>>>>>> `network/cni`
>>>>>>> >> isolator
>>>>>>> >> > is
>>>>>>> >> >
>>>>>>> >> >     able to allocate a network namespace to Mesos containers
>>>>>>> and attach
>>>>>>> >> the
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     container to different types of IP networks by invoking
>>>>>>> network
>>>>>>> >> drivers
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     called CNI plugins.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>>>>> >> refactored
>>>>>>> >> > in
>>>>>>> >> >
>>>>>>> >> >     order to decouple the ACLs definition language from the
>>>>>>> interface.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     It additionally includes the option of retrieving
>>>>>>> `ObjectApprover`.
>>>>>>> >> An
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>>>>> authorizations
>>>>>>> >> for
>>>>>>> >> > a
>>>>>>> >> >
>>>>>>> >> >     given object and is hence useful when authorizing a large
>>>>>>> number of
>>>>>>> >> > objects
>>>>>>> >> >
>>>>>>> >> >     and/or large objects (which need to be copied using request
>>>>>>> based
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>>>>> authorizer
>>>>>>> >> > modules.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>>>>> >> > authorization::Request
>>>>>>> >> >
>>>>>>> >> >     have been changed from required to optional. If either of
>>>>>>> these
>>>>>>> >> fields
>>>>>>> >> > is
>>>>>>> >> >
>>>>>>> >> >     not set, the request should only be authorized if any
>>>>>>> subject/object
>>>>>>> >> > should
>>>>>>> >> >
>>>>>>> >> >     be allowed.
>>>>>>> >> >
>>>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
>>>>>>> HTTP
>>>>>>> >> > endpoint
>>>>>>> >> >
>>>>>>> >> >     filtering enables operators to restrict what part of the
>>>>>>> cluster
>>>>>>> >> state
>>>>>>> >> > a
>>>>>>> >> >
>>>>>>> >> >     user is authorized to see.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     Consider for example the `/state` master endpoint: an
>>>>>>> operator can
>>>>>>> >> now
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     authorize users to only see a subset of the running
>>>>>>> frameworks,
>>>>>>> >> tasks,
>>>>>>> >> > or
>>>>>>> >> >
>>>>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>>>>> filtering:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     '/state', '/state-summary', '/tasks',
>>>>>>> '/frameworks','/weights',
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>>>>> >> filtering:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>>>>> >> > 'GET_TASKS'.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>>>>> >> > best-effort,
>>>>>>> >> >
>>>>>>> >> >     because machine failures or forcible terminations may occur.
>>>>>>> >> Currently,
>>>>>>> >> > the
>>>>>>> >> >
>>>>>>> >> >     only available kill policy is how long to wait between
>>>>>>> graceful and
>>>>>>> >> > forcible
>>>>>>> >> >
>>>>>>> >> >     task kill. In the future, more policies may be available
>>>>>>> (e.g.
>>>>>>> >> hitting
>>>>>>> >> > an
>>>>>>> >> >
>>>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>>>>> >> executor's
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>>>>> >> > command-based
>>>>>>> >> >
>>>>>>> >> >     tasks, the kill is performed via sending a signal to the
>>>>>>> task
>>>>>>> >> process:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>>>>> kill. For
>>>>>>> >> > docker
>>>>>>> >> >
>>>>>>> >> >     executor-less tasks the grace period is passed to 'docker
>>>>>>> stop
>>>>>>> >> --time'.
>>>>>>> >> > This
>>>>>>> >> >
>>>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>>>>> >> > deprecated.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4908] - The task kill policy defined within
>>>>>>> 'TaskInfo' can
>>>>>>> >> now
>>>>>>> >> > be
>>>>>>> >> >
>>>>>>> >> >     overridden when the scheduler kills the task. This can be
>>>>>>> used by
>>>>>>> >> > schedulers
>>>>>>> >> >
>>>>>>> >> >     to forcefully kill a task which is already being killed,
>>>>>>> e.g. if
>>>>>>> >> > something
>>>>>>> >> >
>>>>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>>>>> desired.
>>>>>>> >> Note
>>>>>>> >> > that
>>>>>>> >> >
>>>>>>> >> >     it is the executor's responsibility to honor the
>>>>>>> >> > 'Event.kill.kill_policy'
>>>>>>> >> >
>>>>>>> >> >     field and override the task's kill policy and kill policy
>>>>>>> from a
>>>>>>> >> > previous
>>>>>>> >> >
>>>>>>> >> >     kill task request. To use this feature, schedulers and
>>>>>>> executors
>>>>>>> >> must
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
>>>>>>> flag to
>>>>>>> >> > ensure
>>>>>>> >> >
>>>>>>> >> >     the agent launches the HTTP API based command executor.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>>>>> >> configured
>>>>>>> >> > in
>>>>>>> >> >
>>>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When
>>>>>>> shutting down
>>>>>>> >> an
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     executor the agent will wait in a best-effort manner for
>>>>>>> the grace
>>>>>>> >> > period
>>>>>>> >> >
>>>>>>> >> >     specified here before forcibly destroying the container. The
>>>>>>> >> executor
>>>>>>> >> > must
>>>>>>> >> >
>>>>>>> >> >     not assume that it will always be allotted the full grace
>>>>>>> period, as
>>>>>>> >> > the
>>>>>>> >> >
>>>>>>> >> >     agent may decide to allot a shorter period and failures /
>>>>>>> forcible
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     terminations may occur. Together with kill policies this
>>>>>>> gives
>>>>>>> >> > frameworks
>>>>>>> >> >
>>>>>>> >> >     flexibility around how to clean up tasks and executors.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>>>>> tasks on
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     Windows. Note that there are no isolation guarantees
>>>>>>> provided yet.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
>>>>>>> split into
>>>>>>> >> > two,
>>>>>>> >> >
>>>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>>>>> removes
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor`
>>>>>>> and
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining
>>>>>>> both
>>>>>>> >> modules
>>>>>>> >> > for
>>>>>>> >> >
>>>>>>> >> >     backwards compatibility with existing code.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>>>>> complete. To
>>>>>>> >> > support
>>>>>>> >> >
>>>>>>> >> >     the rename, new duplicate flags (e.g.,
>>>>>>> --agent_reregister_timeout),
>>>>>>> >> new
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have
>>>>>>> been
>>>>>>> >> added.
>>>>>>> >> > All
>>>>>>> >> >
>>>>>>> >> >     the logging output has been updated to use the term 'agent'
>>>>>>> now.
>>>>>>> >> Flags,
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     binaries and scripts with 'slave' keyword have been
>>>>>>> deprecated (see
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     "Deprecations section below").
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>>>>> running
>>>>>>> >> mesos
>>>>>>> >> > on
>>>>>>> >> >
>>>>>>> >> >     IBM PowerPC platform.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
>>>>>>> configured
>>>>>>> >> > dynamically
>>>>>>> >> >
>>>>>>> >> >     via the new '/weights' endpoint on the master.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource
>>>>>>> in the
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>>>>> >> containers
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     with and without filesystem isolation (i.e. running both
>>>>>>> imageless
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     containers as well as containers using a docker image).
>>>>>>> Frameworks
>>>>>>> >> must
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>>>>> framework
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     capability (see the scarce resource problem in MESOS-5377).
>>>>>>> We
>>>>>>> >> support
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     'nvidia-docker'-style docker containers by injecting a
>>>>>>> volume that
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     contains the Nvidia libraries / binaries when the docker
>>>>>>> image has
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the
>>>>>>> docker
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >     containerizer will come in a future release.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>>>>> additional IP
>>>>>>> >> > address
>>>>>>> >> >
>>>>>>> >> >     subject alternative name extension verification.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The CHANGELOG for the release is available at:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> --------------------------------------------------------------------------------
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The MD5 checksum of the tarball can be found at:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The signature of the tarball can be found at:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The PGP key used to sign the release is here:
>>>>>>> >> >
>>>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The JAR is up in Maven in a staging repository here:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes
>>>>>>> if a
>>>>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>>>>> >> >
>>>>>>> >> > [ ] -1 Do not release this package because ...
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Thanks,
>>>>>>> >> >
>>>>>>> >> > Vinod
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Cheers,
>>>>>>> >
>>>>>>> > Zhitao Li
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>>
>>>>>> Zhitao Li
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>>
>>
>>
>>
>> --
>> Deshi Xiao
>> Twitter: xds2000
>> E-mail: xiaods(AT)gmail.com
>>
>
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Jörg Schad <jo...@mesosphere.io>]

+1 non-binding

{OSX, Ubuntu 16)
- sudo make check
- upgrade script

Short question: until when is this vote open?

On Sat, Jul 16, 2016 at 7:40 AM, tommy xiao <xi...@gmail.com> wrote:

> +1
>
> Tested on Fedora release 23 (Twenty Three)
>
> - make check
> - 1.0.0-rc2
>
> 2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:
>
>> +1
>>
>> Tested on CentOS 7.
>>
>> - sudo make check
>> - upgrade from 0.28.2 to 1.0.0-rc2
>>
>> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> Haosdent investigated the issue, and it seems that health checks do work
>>> for docker executor. Hence I retract my negative vote.
>>>
>>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
>>> wrote:
>>>
>>>> -1 (binding): MESOS-5848
>>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>>>> way.
>>>>
>>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
>>>> wrote:
>>>>
>>>>> +1 (nonbinding)
>>>>>
>>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>>>> downgrade on a small test cluster for both master and slave.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>>>> wrote:
>>>>>
>>>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>>>> build
>>>>>> will be 1.0.0. Sorry for the confusion.
>>>>>>
>>>>>> Kapil
>>>>>>
>>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Hi Kapil,
>>>>>> >
>>>>>> > Do you mean that the stable builds from
>>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>>>> configuration?
>>>>>> >
>>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>>>> wrote:
>>>>>> >
>>>>>> >> The binary rpm/deb packages can be found here:
>>>>>> >>
>>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>>>> >> .
>>>>>> >>
>>>>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>>>> >> module dependency installation. Here is the configure command line:
>>>>>> >>     ./configure --enable-libevent --enable-ssl
>>>>>> >> --enable-install-module-dependencies
>>>>>> >>
>>>>>> >> As always, the stable builds are available at:
>>>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>>>> >>
>>>>>> >> The instructions for nightly builds are available at:
>>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>>>> >>
>>>>>> >> Best,
>>>>>> >> Kapil
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > Hi all,
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>>>>> 1.0.0.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > 1.0.0 includes the following:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> --------------------------------------------------------------------------------
>>>>>> >> >
>>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered
>>>>>> stable.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
>>>>>> Agent
>>>>>> >> APIs.
>>>>>> >> > These
>>>>>> >> >
>>>>>> >> >     APIs let operators and services (monitoring, load balancers)
>>>>>> send
>>>>>> >> HTTP
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     `docs/operator-http-api.md` for details.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>>>> >> isolator
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     has been added to isolate disk resources more efficiently.
>>>>>> Please
>>>>>> >> refer
>>>>>> >> > to
>>>>>> >> >
>>>>>> >> >     docs/mesos-containerizer.md for more details.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>>>> plugin. We
>>>>>> >> > added a
>>>>>> >> >
>>>>>> >> >     new isolator 'docker/volume' which allows users to use
>>>>>> external
>>>>>> >> volumes
>>>>>> >> > in
>>>>>> >> >
>>>>>> >> >     Mesos containerizer. Currently, the isolator interacts with
>>>>>> the
>>>>>> >> Docker
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>>>>> Docker
>>>>>> >> > volume
>>>>>> >> >
>>>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     `network/cni` isolator, has been introduced in the
>>>>>> >> > `MesosContainerizer`. The
>>>>>> >> >
>>>>>> >> >     `network/cni` isolator implements the Container Network
>>>>>> Interface
>>>>>> >> (CNI)
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>>>>> >> isolator
>>>>>> >> > is
>>>>>> >> >
>>>>>> >> >     able to allocate a network namespace to Mesos containers and
>>>>>> attach
>>>>>> >> the
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     container to different types of IP networks by invoking
>>>>>> network
>>>>>> >> drivers
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     called CNI plugins.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>>>> >> refactored
>>>>>> >> > in
>>>>>> >> >
>>>>>> >> >     order to decouple the ACLs definition language from the
>>>>>> interface.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     It additionally includes the option of retrieving
>>>>>> `ObjectApprover`.
>>>>>> >> An
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>>>> authorizations
>>>>>> >> for
>>>>>> >> > a
>>>>>> >> >
>>>>>> >> >     given object and is hence useful when authorizing a large
>>>>>> number of
>>>>>> >> > objects
>>>>>> >> >
>>>>>> >> >     and/or large objects (which need to be copied using request
>>>>>> based
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>>>> authorizer
>>>>>> >> > modules.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>>>> >> > authorization::Request
>>>>>> >> >
>>>>>> >> >     have been changed from required to optional. If either of
>>>>>> these
>>>>>> >> fields
>>>>>> >> > is
>>>>>> >> >
>>>>>> >> >     not set, the request should only be authorized if any
>>>>>> subject/object
>>>>>> >> > should
>>>>>> >> >
>>>>>> >> >     be allowed.
>>>>>> >> >
>>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
>>>>>> HTTP
>>>>>> >> > endpoint
>>>>>> >> >
>>>>>> >> >     filtering enables operators to restrict what part of the
>>>>>> cluster
>>>>>> >> state
>>>>>> >> > a
>>>>>> >> >
>>>>>> >> >     user is authorized to see.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     Consider for example the `/state` master endpoint: an
>>>>>> operator can
>>>>>> >> now
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     authorize users to only see a subset of the running
>>>>>> frameworks,
>>>>>> >> tasks,
>>>>>> >> > or
>>>>>> >> >
>>>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>>>> filtering:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     '/state', '/state-summary', '/tasks',
>>>>>> '/frameworks','/weights',
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>>>> >> filtering:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>>>> >> > 'GET_TASKS'.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>>>> >> > best-effort,
>>>>>> >> >
>>>>>> >> >     because machine failures or forcible terminations may occur.
>>>>>> >> Currently,
>>>>>> >> > the
>>>>>> >> >
>>>>>> >> >     only available kill policy is how long to wait between
>>>>>> graceful and
>>>>>> >> > forcible
>>>>>> >> >
>>>>>> >> >     task kill. In the future, more policies may be available
>>>>>> (e.g.
>>>>>> >> hitting
>>>>>> >> > an
>>>>>> >> >
>>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>>>> >> executor's
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>>>> >> > command-based
>>>>>> >> >
>>>>>> >> >     tasks, the kill is performed via sending a signal to the task
>>>>>> >> process:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>>>> kill. For
>>>>>> >> > docker
>>>>>> >> >
>>>>>> >> >     executor-less tasks the grace period is passed to 'docker
>>>>>> stop
>>>>>> >> --time'.
>>>>>> >> > This
>>>>>> >> >
>>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>>>> >> > deprecated.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4908] - The task kill policy defined within
>>>>>> 'TaskInfo' can
>>>>>> >> now
>>>>>> >> > be
>>>>>> >> >
>>>>>> >> >     overridden when the scheduler kills the task. This can be
>>>>>> used by
>>>>>> >> > schedulers
>>>>>> >> >
>>>>>> >> >     to forcefully kill a task which is already being killed,
>>>>>> e.g. if
>>>>>> >> > something
>>>>>> >> >
>>>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>>>> desired.
>>>>>> >> Note
>>>>>> >> > that
>>>>>> >> >
>>>>>> >> >     it is the executor's responsibility to honor the
>>>>>> >> > 'Event.kill.kill_policy'
>>>>>> >> >
>>>>>> >> >     field and override the task's kill policy and kill policy
>>>>>> from a
>>>>>> >> > previous
>>>>>> >> >
>>>>>> >> >     kill task request. To use this feature, schedulers and
>>>>>> executors
>>>>>> >> must
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
>>>>>> flag to
>>>>>> >> > ensure
>>>>>> >> >
>>>>>> >> >     the agent launches the HTTP API based command executor.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>>>> >> configured
>>>>>> >> > in
>>>>>> >> >
>>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When
>>>>>> shutting down
>>>>>> >> an
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     executor the agent will wait in a best-effort manner for the
>>>>>> grace
>>>>>> >> > period
>>>>>> >> >
>>>>>> >> >     specified here before forcibly destroying the container. The
>>>>>> >> executor
>>>>>> >> > must
>>>>>> >> >
>>>>>> >> >     not assume that it will always be allotted the full grace
>>>>>> period, as
>>>>>> >> > the
>>>>>> >> >
>>>>>> >> >     agent may decide to allot a shorter period and failures /
>>>>>> forcible
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     terminations may occur. Together with kill policies this
>>>>>> gives
>>>>>> >> > frameworks
>>>>>> >> >
>>>>>> >> >     flexibility around how to clean up tasks and executors.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>>>> tasks on
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     Windows. Note that there are no isolation guarantees
>>>>>> provided yet.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
>>>>>> split into
>>>>>> >> > two,
>>>>>> >> >
>>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>>>> removes
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining
>>>>>> both
>>>>>> >> modules
>>>>>> >> > for
>>>>>> >> >
>>>>>> >> >     backwards compatibility with existing code.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>>>> complete. To
>>>>>> >> > support
>>>>>> >> >
>>>>>> >> >     the rename, new duplicate flags (e.g.,
>>>>>> --agent_reregister_timeout),
>>>>>> >> new
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have
>>>>>> been
>>>>>> >> added.
>>>>>> >> > All
>>>>>> >> >
>>>>>> >> >     the logging output has been updated to use the term 'agent'
>>>>>> now.
>>>>>> >> Flags,
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     binaries and scripts with 'slave' keyword have been
>>>>>> deprecated (see
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     "Deprecations section below").
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>>>> running
>>>>>> >> mesos
>>>>>> >> > on
>>>>>> >> >
>>>>>> >> >     IBM PowerPC platform.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
>>>>>> configured
>>>>>> >> > dynamically
>>>>>> >> >
>>>>>> >> >     via the new '/weights' endpoint on the master.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource
>>>>>> in the
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>>>> >> containers
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     with and without filesystem isolation (i.e. running both
>>>>>> imageless
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     containers as well as containers using a docker image).
>>>>>> Frameworks
>>>>>> >> must
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>>>> framework
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     capability (see the scarce resource problem in MESOS-5377).
>>>>>> We
>>>>>> >> support
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     'nvidia-docker'-style docker containers by injecting a
>>>>>> volume that
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     contains the Nvidia libraries / binaries when the docker
>>>>>> image has
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >     containerizer will come in a future release.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>>>> additional IP
>>>>>> >> > address
>>>>>> >> >
>>>>>> >> >     subject alternative name extension verification.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The CHANGELOG for the release is available at:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> --------------------------------------------------------------------------------
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The MD5 checksum of the tarball can be found at:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The signature of the tarball can be found at:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The PGP key used to sign the release is here:
>>>>>> >> >
>>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The JAR is up in Maven in a staging repository here:
>>>>>> >> >
>>>>>> >> >
>>>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes
>>>>>> if a
>>>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>>>> >> >
>>>>>> >> > [ ] -1 Do not release this package because ...
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Thanks,
>>>>>> >> >
>>>>>> >> > Vinod
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Cheers,
>>>>>> >
>>>>>> > Zhitao Li
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>
>>>>> Zhitao Li
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
>
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[tommy xiao <xi...@gmail.com>]

+1

Tested on Fedora release 23 (Twenty Three)

- make check
- 1.0.0-rc2

2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:

> +1
>
> Tested on CentOS 7.
>
> - sudo make check
> - upgrade from 0.28.2 to 1.0.0-rc2
>
> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> Haosdent investigated the issue, and it seems that health checks do work
>> for docker executor. Hence I retract my negative vote.
>>
>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> -1 (binding): MESOS-5848
>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>>> way.
>>>
>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>>> +1 (nonbinding)
>>>>
>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>>> downgrade on a small test cluster for both master and slave.
>>>>
>>>>
>>>>
>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>>
>>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>>> build
>>>>> will be 1.0.0. Sorry for the confusion.
>>>>>
>>>>> Kapil
>>>>>
>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi Kapil,
>>>>> >
>>>>> > Do you mean that the stable builds from
>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>>> configuration?
>>>>> >
>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>>> wrote:
>>>>> >
>>>>> >> The binary rpm/deb packages can be found here:
>>>>> >>
>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>>> >> .
>>>>> >>
>>>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>>> >> module dependency installation. Here is the configure command line:
>>>>> >>     ./configure --enable-libevent --enable-ssl
>>>>> >> --enable-install-module-dependencies
>>>>> >>
>>>>> >> As always, the stable builds are available at:
>>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>>> >>
>>>>> >> The instructions for nightly builds are available at:
>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>>> >>
>>>>> >> Best,
>>>>> >> Kapil
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>>> wrote:
>>>>> >> >
>>>>> >> > Hi all,
>>>>> >> >
>>>>> >> >
>>>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>>>> 1.0.0.
>>>>> >> >
>>>>> >> >
>>>>> >> > 1.0.0 includes the following:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> --------------------------------------------------------------------------------
>>>>> >> >
>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
>>>>> Agent
>>>>> >> APIs.
>>>>> >> > These
>>>>> >> >
>>>>> >> >     APIs let operators and services (monitoring, load balancers)
>>>>> send
>>>>> >> HTTP
>>>>> >> >
>>>>> >> >
>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>>> >> >
>>>>> >> >
>>>>> >> >     `docs/operator-http-api.md` for details.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>>> >> isolator
>>>>> >> >
>>>>> >> >
>>>>> >> >     has been added to isolate disk resources more efficiently.
>>>>> Please
>>>>> >> refer
>>>>> >> > to
>>>>> >> >
>>>>> >> >     docs/mesos-containerizer.md for more details.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>>> plugin. We
>>>>> >> > added a
>>>>> >> >
>>>>> >> >     new isolator 'docker/volume' which allows users to use
>>>>> external
>>>>> >> volumes
>>>>> >> > in
>>>>> >> >
>>>>> >> >     Mesos containerizer. Currently, the isolator interacts with
>>>>> the
>>>>> >> Docker
>>>>> >> >
>>>>> >> >
>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>>>> Docker
>>>>> >> > volume
>>>>> >> >
>>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>>> >> >
>>>>> >> >
>>>>> >> >     `network/cni` isolator, has been introduced in the
>>>>> >> > `MesosContainerizer`. The
>>>>> >> >
>>>>> >> >     `network/cni` isolator implements the Container Network
>>>>> Interface
>>>>> >> (CNI)
>>>>> >> >
>>>>> >> >
>>>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>>>> >> isolator
>>>>> >> > is
>>>>> >> >
>>>>> >> >     able to allocate a network namespace to Mesos containers and
>>>>> attach
>>>>> >> the
>>>>> >> >
>>>>> >> >
>>>>> >> >     container to different types of IP networks by invoking
>>>>> network
>>>>> >> drivers
>>>>> >> >
>>>>> >> >
>>>>> >> >     called CNI plugins.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>>> >> refactored
>>>>> >> > in
>>>>> >> >
>>>>> >> >     order to decouple the ACLs definition language from the
>>>>> interface.
>>>>> >> >
>>>>> >> >
>>>>> >> >     It additionally includes the option of retrieving
>>>>> `ObjectApprover`.
>>>>> >> An
>>>>> >> >
>>>>> >> >
>>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>>> authorizations
>>>>> >> for
>>>>> >> > a
>>>>> >> >
>>>>> >> >     given object and is hence useful when authorizing a large
>>>>> number of
>>>>> >> > objects
>>>>> >> >
>>>>> >> >     and/or large objects (which need to be copied using request
>>>>> based
>>>>> >> >
>>>>> >> >
>>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>>> authorizer
>>>>> >> > modules.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>>> >> > authorization::Request
>>>>> >> >
>>>>> >> >     have been changed from required to optional. If either of
>>>>> these
>>>>> >> fields
>>>>> >> > is
>>>>> >> >
>>>>> >> >     not set, the request should only be authorized if any
>>>>> subject/object
>>>>> >> > should
>>>>> >> >
>>>>> >> >     be allowed.
>>>>> >> >
>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
>>>>> HTTP
>>>>> >> > endpoint
>>>>> >> >
>>>>> >> >     filtering enables operators to restrict what part of the
>>>>> cluster
>>>>> >> state
>>>>> >> > a
>>>>> >> >
>>>>> >> >     user is authorized to see.
>>>>> >> >
>>>>> >> >
>>>>> >> >     Consider for example the `/state` master endpoint: an
>>>>> operator can
>>>>> >> now
>>>>> >> >
>>>>> >> >
>>>>> >> >     authorize users to only see a subset of the running
>>>>> frameworks,
>>>>> >> tasks,
>>>>> >> > or
>>>>> >> >
>>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>>> filtering:
>>>>> >> >
>>>>> >> >
>>>>> >> >     '/state', '/state-summary', '/tasks',
>>>>> '/frameworks','/weights',
>>>>> >> >
>>>>> >> >
>>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>>> >> filtering:
>>>>> >> >
>>>>> >> >
>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>>> >> > 'GET_TASKS'.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>>> >> > best-effort,
>>>>> >> >
>>>>> >> >     because machine failures or forcible terminations may occur.
>>>>> >> Currently,
>>>>> >> > the
>>>>> >> >
>>>>> >> >     only available kill policy is how long to wait between
>>>>> graceful and
>>>>> >> > forcible
>>>>> >> >
>>>>> >> >     task kill. In the future, more policies may be available (e.g.
>>>>> >> hitting
>>>>> >> > an
>>>>> >> >
>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>>> >> executor's
>>>>> >> >
>>>>> >> >
>>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>>> >> > command-based
>>>>> >> >
>>>>> >> >     tasks, the kill is performed via sending a signal to the task
>>>>> >> process:
>>>>> >> >
>>>>> >> >
>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>>> kill. For
>>>>> >> > docker
>>>>> >> >
>>>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>>>> >> --time'.
>>>>> >> > This
>>>>> >> >
>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>>> >> > deprecated.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>>>> can
>>>>> >> now
>>>>> >> > be
>>>>> >> >
>>>>> >> >     overridden when the scheduler kills the task. This can be
>>>>> used by
>>>>> >> > schedulers
>>>>> >> >
>>>>> >> >     to forcefully kill a task which is already being killed, e.g.
>>>>> if
>>>>> >> > something
>>>>> >> >
>>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>>> desired.
>>>>> >> Note
>>>>> >> > that
>>>>> >> >
>>>>> >> >     it is the executor's responsibility to honor the
>>>>> >> > 'Event.kill.kill_policy'
>>>>> >> >
>>>>> >> >     field and override the task's kill policy and kill policy
>>>>> from a
>>>>> >> > previous
>>>>> >> >
>>>>> >> >     kill task request. To use this feature, schedulers and
>>>>> executors
>>>>> >> must
>>>>> >> >
>>>>> >> >
>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
>>>>> flag to
>>>>> >> > ensure
>>>>> >> >
>>>>> >> >     the agent launches the HTTP API based command executor.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>>> >> configured
>>>>> >> > in
>>>>> >> >
>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>>>> down
>>>>> >> an
>>>>> >> >
>>>>> >> >
>>>>> >> >     executor the agent will wait in a best-effort manner for the
>>>>> grace
>>>>> >> > period
>>>>> >> >
>>>>> >> >     specified here before forcibly destroying the container. The
>>>>> >> executor
>>>>> >> > must
>>>>> >> >
>>>>> >> >     not assume that it will always be allotted the full grace
>>>>> period, as
>>>>> >> > the
>>>>> >> >
>>>>> >> >     agent may decide to allot a shorter period and failures /
>>>>> forcible
>>>>> >> >
>>>>> >> >
>>>>> >> >     terminations may occur. Together with kill policies this gives
>>>>> >> > frameworks
>>>>> >> >
>>>>> >> >     flexibility around how to clean up tasks and executors.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>>> tasks on
>>>>> >> >
>>>>> >> >
>>>>> >> >     Windows. Note that there are no isolation guarantees provided
>>>>> yet.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
>>>>> split into
>>>>> >> > two,
>>>>> >> >
>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>>> removes
>>>>> >> >
>>>>> >> >
>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>>>> >> >
>>>>> >> >
>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>>>> >> modules
>>>>> >> > for
>>>>> >> >
>>>>> >> >     backwards compatibility with existing code.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>>> complete. To
>>>>> >> > support
>>>>> >> >
>>>>> >> >     the rename, new duplicate flags (e.g.,
>>>>> --agent_reregister_timeout),
>>>>> >> new
>>>>> >> >
>>>>> >> >
>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>>>> >> added.
>>>>> >> > All
>>>>> >> >
>>>>> >> >     the logging output has been updated to use the term 'agent'
>>>>> now.
>>>>> >> Flags,
>>>>> >> >
>>>>> >> >
>>>>> >> >     binaries and scripts with 'slave' keyword have been
>>>>> deprecated (see
>>>>> >> >
>>>>> >> >
>>>>> >> >     "Deprecations section below").
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>>> running
>>>>> >> mesos
>>>>> >> > on
>>>>> >> >
>>>>> >> >     IBM PowerPC platform.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
>>>>> configured
>>>>> >> > dynamically
>>>>> >> >
>>>>> >> >     via the new '/weights' endpoint on the master.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>>>> the
>>>>> >> >
>>>>> >> >
>>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>>> >> containers
>>>>> >> >
>>>>> >> >
>>>>> >> >     with and without filesystem isolation (i.e. running both
>>>>> imageless
>>>>> >> >
>>>>> >> >
>>>>> >> >     containers as well as containers using a docker image).
>>>>> Frameworks
>>>>> >> must
>>>>> >> >
>>>>> >> >
>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>>> framework
>>>>> >> >
>>>>> >> >
>>>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>>>> >> support
>>>>> >> >
>>>>> >> >
>>>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>>>> that
>>>>> >> >
>>>>> >> >
>>>>> >> >     contains the Nvidia libraries / binaries when the docker
>>>>> image has
>>>>> >> >
>>>>> >> >
>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>>>> >> >
>>>>> >> >
>>>>> >> >     containerizer will come in a future release.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>>> additional IP
>>>>> >> > address
>>>>> >> >
>>>>> >> >     subject alternative name extension verification.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > The CHANGELOG for the release is available at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> --------------------------------------------------------------------------------
>>>>> >> >
>>>>> >> >
>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>>> >> >
>>>>> >> >
>>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>>> >> >
>>>>> >> >
>>>>> >> > The MD5 checksum of the tarball can be found at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>>> >> >
>>>>> >> >
>>>>> >> > The signature of the tarball can be found at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>>> >> >
>>>>> >> >
>>>>> >> > The PGP key used to sign the release is here:
>>>>> >> >
>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>>> >> >
>>>>> >> >
>>>>> >> > The JAR is up in Maven in a staging repository here:
>>>>> >> >
>>>>> >> >
>>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>>> >> >
>>>>> >> >
>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>>> >> >
>>>>> >> >
>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if
>>>>> a
>>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>>> >> >
>>>>> >> >
>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>>> >> >
>>>>> >> > [ ] -1 Do not release this package because ...
>>>>> >> >
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> >
>>>>> >> > Vinod
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Cheers,
>>>>> >
>>>>> > Zhitao Li
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>
>>>> Zhitao Li
>>>>
>>>
>>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[tommy xiao <xi...@gmail.com>]

+1

Tested on Fedora release 23 (Twenty Three)

- make check
- 1.0.0-rc2

2016-07-15 23:01 GMT+08:00 haosdent <ha...@gmail.com>:

> +1
>
> Tested on CentOS 7.
>
> - sudo make check
> - upgrade from 0.28.2 to 1.0.0-rc2
>
> On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> Haosdent investigated the issue, and it seems that health checks do work
>> for docker executor. Hence I retract my negative vote.
>>
>> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> -1 (binding): MESOS-5848
>>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>>> way.
>>>
>>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>>> +1 (nonbinding)
>>>>
>>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>>> downgrade on a small test cluster for both master and slave.
>>>>
>>>>
>>>>
>>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>>
>>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>>> build
>>>>> will be 1.0.0. Sorry for the confusion.
>>>>>
>>>>> Kapil
>>>>>
>>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi Kapil,
>>>>> >
>>>>> > Do you mean that the stable builds from
>>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>>> configuration?
>>>>> >
>>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>>> wrote:
>>>>> >
>>>>> >> The binary rpm/deb packages can be found here:
>>>>> >>
>>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>>> >> .
>>>>> >>
>>>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>>> >> module dependency installation. Here is the configure command line:
>>>>> >>     ./configure --enable-libevent --enable-ssl
>>>>> >> --enable-install-module-dependencies
>>>>> >>
>>>>> >> As always, the stable builds are available at:
>>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>>> >>
>>>>> >> The instructions for nightly builds are available at:
>>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>>> >>
>>>>> >> Best,
>>>>> >> Kapil
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>>> wrote:
>>>>> >> >
>>>>> >> > Hi all,
>>>>> >> >
>>>>> >> >
>>>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>>>> 1.0.0.
>>>>> >> >
>>>>> >> >
>>>>> >> > 1.0.0 includes the following:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> --------------------------------------------------------------------------------
>>>>> >> >
>>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and
>>>>> Agent
>>>>> >> APIs.
>>>>> >> > These
>>>>> >> >
>>>>> >> >     APIs let operators and services (monitoring, load balancers)
>>>>> send
>>>>> >> HTTP
>>>>> >> >
>>>>> >> >
>>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>>> >> >
>>>>> >> >
>>>>> >> >     `docs/operator-http-api.md` for details.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>>> >> isolator
>>>>> >> >
>>>>> >> >
>>>>> >> >     has been added to isolate disk resources more efficiently.
>>>>> Please
>>>>> >> refer
>>>>> >> > to
>>>>> >> >
>>>>> >> >     docs/mesos-containerizer.md for more details.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>>> plugin. We
>>>>> >> > added a
>>>>> >> >
>>>>> >> >     new isolator 'docker/volume' which allows users to use
>>>>> external
>>>>> >> volumes
>>>>> >> > in
>>>>> >> >
>>>>> >> >     Mesos containerizer. Currently, the isolator interacts with
>>>>> the
>>>>> >> Docker
>>>>> >> >
>>>>> >> >
>>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>>>> Docker
>>>>> >> > volume
>>>>> >> >
>>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>>> >> >
>>>>> >> >
>>>>> >> >     `network/cni` isolator, has been introduced in the
>>>>> >> > `MesosContainerizer`. The
>>>>> >> >
>>>>> >> >     `network/cni` isolator implements the Container Network
>>>>> Interface
>>>>> >> (CNI)
>>>>> >> >
>>>>> >> >
>>>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>>>> >> isolator
>>>>> >> > is
>>>>> >> >
>>>>> >> >     able to allocate a network namespace to Mesos containers and
>>>>> attach
>>>>> >> the
>>>>> >> >
>>>>> >> >
>>>>> >> >     container to different types of IP networks by invoking
>>>>> network
>>>>> >> drivers
>>>>> >> >
>>>>> >> >
>>>>> >> >     called CNI plugins.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>>> >> refactored
>>>>> >> > in
>>>>> >> >
>>>>> >> >     order to decouple the ACLs definition language from the
>>>>> interface.
>>>>> >> >
>>>>> >> >
>>>>> >> >     It additionally includes the option of retrieving
>>>>> `ObjectApprover`.
>>>>> >> An
>>>>> >> >
>>>>> >> >
>>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>>> authorizations
>>>>> >> for
>>>>> >> > a
>>>>> >> >
>>>>> >> >     given object and is hence useful when authorizing a large
>>>>> number of
>>>>> >> > objects
>>>>> >> >
>>>>> >> >     and/or large objects (which need to be copied using request
>>>>> based
>>>>> >> >
>>>>> >> >
>>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>>> authorizer
>>>>> >> > modules.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>>> >> > authorization::Request
>>>>> >> >
>>>>> >> >     have been changed from required to optional. If either of
>>>>> these
>>>>> >> fields
>>>>> >> > is
>>>>> >> >
>>>>> >> >     not set, the request should only be authorized if any
>>>>> subject/object
>>>>> >> > should
>>>>> >> >
>>>>> >> >     be allowed.
>>>>> >> >
>>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based
>>>>> HTTP
>>>>> >> > endpoint
>>>>> >> >
>>>>> >> >     filtering enables operators to restrict what part of the
>>>>> cluster
>>>>> >> state
>>>>> >> > a
>>>>> >> >
>>>>> >> >     user is authorized to see.
>>>>> >> >
>>>>> >> >
>>>>> >> >     Consider for example the `/state` master endpoint: an
>>>>> operator can
>>>>> >> now
>>>>> >> >
>>>>> >> >
>>>>> >> >     authorize users to only see a subset of the running
>>>>> frameworks,
>>>>> >> tasks,
>>>>> >> > or
>>>>> >> >
>>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>>> filtering:
>>>>> >> >
>>>>> >> >
>>>>> >> >     '/state', '/state-summary', '/tasks',
>>>>> '/frameworks','/weights',
>>>>> >> >
>>>>> >> >
>>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>>> >> filtering:
>>>>> >> >
>>>>> >> >
>>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>>> >> > 'GET_TASKS'.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>>> >> > best-effort,
>>>>> >> >
>>>>> >> >     because machine failures or forcible terminations may occur.
>>>>> >> Currently,
>>>>> >> > the
>>>>> >> >
>>>>> >> >     only available kill policy is how long to wait between
>>>>> graceful and
>>>>> >> > forcible
>>>>> >> >
>>>>> >> >     task kill. In the future, more policies may be available (e.g.
>>>>> >> hitting
>>>>> >> > an
>>>>> >> >
>>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>>> >> executor's
>>>>> >> >
>>>>> >> >
>>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>>> >> > command-based
>>>>> >> >
>>>>> >> >     tasks, the kill is performed via sending a signal to the task
>>>>> >> process:
>>>>> >> >
>>>>> >> >
>>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>>> kill. For
>>>>> >> > docker
>>>>> >> >
>>>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>>>> >> --time'.
>>>>> >> > This
>>>>> >> >
>>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>>> >> > deprecated.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>>>> can
>>>>> >> now
>>>>> >> > be
>>>>> >> >
>>>>> >> >     overridden when the scheduler kills the task. This can be
>>>>> used by
>>>>> >> > schedulers
>>>>> >> >
>>>>> >> >     to forcefully kill a task which is already being killed, e.g.
>>>>> if
>>>>> >> > something
>>>>> >> >
>>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>>> desired.
>>>>> >> Note
>>>>> >> > that
>>>>> >> >
>>>>> >> >     it is the executor's responsibility to honor the
>>>>> >> > 'Event.kill.kill_policy'
>>>>> >> >
>>>>> >> >     field and override the task's kill policy and kill policy
>>>>> from a
>>>>> >> > previous
>>>>> >> >
>>>>> >> >     kill task request. To use this feature, schedulers and
>>>>> executors
>>>>> >> must
>>>>> >> >
>>>>> >> >
>>>>> >> >     support HTTP API; use the '--http_command_executor' agent
>>>>> flag to
>>>>> >> > ensure
>>>>> >> >
>>>>> >> >     the agent launches the HTTP API based command executor.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>>> >> configured
>>>>> >> > in
>>>>> >> >
>>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>>>> down
>>>>> >> an
>>>>> >> >
>>>>> >> >
>>>>> >> >     executor the agent will wait in a best-effort manner for the
>>>>> grace
>>>>> >> > period
>>>>> >> >
>>>>> >> >     specified here before forcibly destroying the container. The
>>>>> >> executor
>>>>> >> > must
>>>>> >> >
>>>>> >> >     not assume that it will always be allotted the full grace
>>>>> period, as
>>>>> >> > the
>>>>> >> >
>>>>> >> >     agent may decide to allot a shorter period and failures /
>>>>> forcible
>>>>> >> >
>>>>> >> >
>>>>> >> >     terminations may occur. Together with kill policies this gives
>>>>> >> > frameworks
>>>>> >> >
>>>>> >> >     flexibility around how to clean up tasks and executors.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>>> tasks on
>>>>> >> >
>>>>> >> >
>>>>> >> >     Windows. Note that there are no isolation guarantees provided
>>>>> yet.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been
>>>>> split into
>>>>> >> > two,
>>>>> >> >
>>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>>> removes
>>>>> >> >
>>>>> >> >
>>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>>>> >> >
>>>>> >> >
>>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>>>> >> modules
>>>>> >> > for
>>>>> >> >
>>>>> >> >     backwards compatibility with existing code.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>>> complete. To
>>>>> >> > support
>>>>> >> >
>>>>> >> >     the rename, new duplicate flags (e.g.,
>>>>> --agent_reregister_timeout),
>>>>> >> new
>>>>> >> >
>>>>> >> >
>>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>>>> >> added.
>>>>> >> > All
>>>>> >> >
>>>>> >> >     the logging output has been updated to use the term 'agent'
>>>>> now.
>>>>> >> Flags,
>>>>> >> >
>>>>> >> >
>>>>> >> >     binaries and scripts with 'slave' keyword have been
>>>>> deprecated (see
>>>>> >> >
>>>>> >> >
>>>>> >> >     "Deprecations section below").
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>>> running
>>>>> >> mesos
>>>>> >> > on
>>>>> >> >
>>>>> >> >     IBM PowerPC platform.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be
>>>>> configured
>>>>> >> > dynamically
>>>>> >> >
>>>>> >> >     via the new '/weights' endpoint on the master.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>>>> the
>>>>> >> >
>>>>> >> >
>>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>>> >> containers
>>>>> >> >
>>>>> >> >
>>>>> >> >     with and without filesystem isolation (i.e. running both
>>>>> imageless
>>>>> >> >
>>>>> >> >
>>>>> >> >     containers as well as containers using a docker image).
>>>>> Frameworks
>>>>> >> must
>>>>> >> >
>>>>> >> >
>>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>>> framework
>>>>> >> >
>>>>> >> >
>>>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>>>> >> support
>>>>> >> >
>>>>> >> >
>>>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>>>> that
>>>>> >> >
>>>>> >> >
>>>>> >> >     contains the Nvidia libraries / binaries when the docker
>>>>> image has
>>>>> >> >
>>>>> >> >
>>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>>>> >> >
>>>>> >> >
>>>>> >> >     containerizer will come in a future release.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>>> additional IP
>>>>> >> > address
>>>>> >> >
>>>>> >> >     subject alternative name extension verification.
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > The CHANGELOG for the release is available at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> --------------------------------------------------------------------------------
>>>>> >> >
>>>>> >> >
>>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>>> >> >
>>>>> >> >
>>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>>> >> >
>>>>> >> >
>>>>> >> > The MD5 checksum of the tarball can be found at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>>> >> >
>>>>> >> >
>>>>> >> > The signature of the tarball can be found at:
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>>> >> >
>>>>> >> >
>>>>> >> > The PGP key used to sign the release is here:
>>>>> >> >
>>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>>> >> >
>>>>> >> >
>>>>> >> > The JAR is up in Maven in a staging repository here:
>>>>> >> >
>>>>> >> >
>>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>>> >> >
>>>>> >> >
>>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>>> >> >
>>>>> >> >
>>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if
>>>>> a
>>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>>> >> >
>>>>> >> >
>>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>>> >> >
>>>>> >> > [ ] -1 Do not release this package because ...
>>>>> >> >
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> >
>>>>> >> > Vinod
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Cheers,
>>>>> >
>>>>> > Zhitao Li
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>
>>>> Zhitao Li
>>>>
>>>
>>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[haosdent <ha...@gmail.com>]

+1

Tested on CentOS 7.

- sudo make check
- upgrade from 0.28.2 to 1.0.0-rc2

On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com> wrote:

> Haosdent investigated the issue, and it seems that health checks do work
> for docker executor. Hence I retract my negative vote.
>
> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> -1 (binding): MESOS-5848
>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>> way.
>>
>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:
>>
>>> +1 (nonbinding)
>>>
>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>> downgrade on a small test cluster for both master and slave.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>>
>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>> build
>>>> will be 1.0.0. Sorry for the confusion.
>>>>
>>>> Kapil
>>>>
>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi Kapil,
>>>> >
>>>> > Do you mean that the stable builds from
>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>> configuration?
>>>> >
>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>> >
>>>> >> The binary rpm/deb packages can be found here:
>>>> >>
>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>> >> .
>>>> >>
>>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>> >> module dependency installation. Here is the configure command line:
>>>> >>     ./configure --enable-libevent --enable-ssl
>>>> >> --enable-install-module-dependencies
>>>> >>
>>>> >> As always, the stable builds are available at:
>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>> >>
>>>> >> The instructions for nightly builds are available at:
>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>> >>
>>>> >> Best,
>>>> >> Kapil
>>>> >>
>>>> >>
>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>> wrote:
>>>> >> >
>>>> >> > Hi all,
>>>> >> >
>>>> >> >
>>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>>> 1.0.0.
>>>> >> >
>>>> >> >
>>>> >> > 1.0.0 includes the following:
>>>> >> >
>>>> >> >
>>>> >>
>>>> --------------------------------------------------------------------------------
>>>> >> >
>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>>>> >> APIs.
>>>> >> > These
>>>> >> >
>>>> >> >     APIs let operators and services (monitoring, load balancers)
>>>> send
>>>> >> HTTP
>>>> >> >
>>>> >> >
>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>> >> >
>>>> >> >
>>>> >> >     `docs/operator-http-api.md` for details.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>> >> isolator
>>>> >> >
>>>> >> >
>>>> >> >     has been added to isolate disk resources more efficiently.
>>>> Please
>>>> >> refer
>>>> >> > to
>>>> >> >
>>>> >> >     docs/mesos-containerizer.md for more details.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>> plugin. We
>>>> >> > added a
>>>> >> >
>>>> >> >     new isolator 'docker/volume' which allows users to use external
>>>> >> volumes
>>>> >> > in
>>>> >> >
>>>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>>>> >> Docker
>>>> >> >
>>>> >> >
>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>>> Docker
>>>> >> > volume
>>>> >> >
>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>> >> >
>>>> >> >
>>>> >> >     `network/cni` isolator, has been introduced in the
>>>> >> > `MesosContainerizer`. The
>>>> >> >
>>>> >> >     `network/cni` isolator implements the Container Network
>>>> Interface
>>>> >> (CNI)
>>>> >> >
>>>> >> >
>>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>>> >> isolator
>>>> >> > is
>>>> >> >
>>>> >> >     able to allocate a network namespace to Mesos containers and
>>>> attach
>>>> >> the
>>>> >> >
>>>> >> >
>>>> >> >     container to different types of IP networks by invoking network
>>>> >> drivers
>>>> >> >
>>>> >> >
>>>> >> >     called CNI plugins.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>> >> refactored
>>>> >> > in
>>>> >> >
>>>> >> >     order to decouple the ACLs definition language from the
>>>> interface.
>>>> >> >
>>>> >> >
>>>> >> >     It additionally includes the option of retrieving
>>>> `ObjectApprover`.
>>>> >> An
>>>> >> >
>>>> >> >
>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>> authorizations
>>>> >> for
>>>> >> > a
>>>> >> >
>>>> >> >     given object and is hence useful when authorizing a large
>>>> number of
>>>> >> > objects
>>>> >> >
>>>> >> >     and/or large objects (which need to be copied using request
>>>> based
>>>> >> >
>>>> >> >
>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>> authorizer
>>>> >> > modules.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>> >> > authorization::Request
>>>> >> >
>>>> >> >     have been changed from required to optional. If either of these
>>>> >> fields
>>>> >> > is
>>>> >> >
>>>> >> >     not set, the request should only be authorized if any
>>>> subject/object
>>>> >> > should
>>>> >> >
>>>> >> >     be allowed.
>>>> >> >
>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>>>> >> > endpoint
>>>> >> >
>>>> >> >     filtering enables operators to restrict what part of the
>>>> cluster
>>>> >> state
>>>> >> > a
>>>> >> >
>>>> >> >     user is authorized to see.
>>>> >> >
>>>> >> >
>>>> >> >     Consider for example the `/state` master endpoint: an operator
>>>> can
>>>> >> now
>>>> >> >
>>>> >> >
>>>> >> >     authorize users to only see a subset of the running frameworks,
>>>> >> tasks,
>>>> >> > or
>>>> >> >
>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>> filtering:
>>>> >> >
>>>> >> >
>>>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>>>> >> >
>>>> >> >
>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>> >> filtering:
>>>> >> >
>>>> >> >
>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>> >> > 'GET_TASKS'.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>> >> > best-effort,
>>>> >> >
>>>> >> >     because machine failures or forcible terminations may occur.
>>>> >> Currently,
>>>> >> > the
>>>> >> >
>>>> >> >     only available kill policy is how long to wait between
>>>> graceful and
>>>> >> > forcible
>>>> >> >
>>>> >> >     task kill. In the future, more policies may be available (e.g.
>>>> >> hitting
>>>> >> > an
>>>> >> >
>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>> >> executor's
>>>> >> >
>>>> >> >
>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>> >> > command-based
>>>> >> >
>>>> >> >     tasks, the kill is performed via sending a signal to the task
>>>> >> process:
>>>> >> >
>>>> >> >
>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>> kill. For
>>>> >> > docker
>>>> >> >
>>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>>> >> --time'.
>>>> >> > This
>>>> >> >
>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>> >> > deprecated.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>>> can
>>>> >> now
>>>> >> > be
>>>> >> >
>>>> >> >     overridden when the scheduler kills the task. This can be used
>>>> by
>>>> >> > schedulers
>>>> >> >
>>>> >> >     to forcefully kill a task which is already being killed, e.g.
>>>> if
>>>> >> > something
>>>> >> >
>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>> desired.
>>>> >> Note
>>>> >> > that
>>>> >> >
>>>> >> >     it is the executor's responsibility to honor the
>>>> >> > 'Event.kill.kill_policy'
>>>> >> >
>>>> >> >     field and override the task's kill policy and kill policy from
>>>> a
>>>> >> > previous
>>>> >> >
>>>> >> >     kill task request. To use this feature, schedulers and
>>>> executors
>>>> >> must
>>>> >> >
>>>> >> >
>>>> >> >     support HTTP API; use the '--http_command_executor' agent flag
>>>> to
>>>> >> > ensure
>>>> >> >
>>>> >> >     the agent launches the HTTP API based command executor.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>> >> configured
>>>> >> > in
>>>> >> >
>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>>> down
>>>> >> an
>>>> >> >
>>>> >> >
>>>> >> >     executor the agent will wait in a best-effort manner for the
>>>> grace
>>>> >> > period
>>>> >> >
>>>> >> >     specified here before forcibly destroying the container. The
>>>> >> executor
>>>> >> > must
>>>> >> >
>>>> >> >     not assume that it will always be allotted the full grace
>>>> period, as
>>>> >> > the
>>>> >> >
>>>> >> >     agent may decide to allot a shorter period and failures /
>>>> forcible
>>>> >> >
>>>> >> >
>>>> >> >     terminations may occur. Together with kill policies this gives
>>>> >> > frameworks
>>>> >> >
>>>> >> >     flexibility around how to clean up tasks and executors.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>> tasks on
>>>> >> >
>>>> >> >
>>>> >> >     Windows. Note that there are no isolation guarantees provided
>>>> yet.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>>>> into
>>>> >> > two,
>>>> >> >
>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>> removes
>>>> >> >
>>>> >> >
>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>>> >> >
>>>> >> >
>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>>> >> modules
>>>> >> > for
>>>> >> >
>>>> >> >     backwards compatibility with existing code.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>> complete. To
>>>> >> > support
>>>> >> >
>>>> >> >     the rename, new duplicate flags (e.g.,
>>>> --agent_reregister_timeout),
>>>> >> new
>>>> >> >
>>>> >> >
>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>>> >> added.
>>>> >> > All
>>>> >> >
>>>> >> >     the logging output has been updated to use the term 'agent'
>>>> now.
>>>> >> Flags,
>>>> >> >
>>>> >> >
>>>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>>>> (see
>>>> >> >
>>>> >> >
>>>> >> >     "Deprecations section below").
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>> running
>>>> >> mesos
>>>> >> > on
>>>> >> >
>>>> >> >     IBM PowerPC platform.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>>>> >> > dynamically
>>>> >> >
>>>> >> >     via the new '/weights' endpoint on the master.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>>> the
>>>> >> >
>>>> >> >
>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>> >> containers
>>>> >> >
>>>> >> >
>>>> >> >     with and without filesystem isolation (i.e. running both
>>>> imageless
>>>> >> >
>>>> >> >
>>>> >> >     containers as well as containers using a docker image).
>>>> Frameworks
>>>> >> must
>>>> >> >
>>>> >> >
>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>> framework
>>>> >> >
>>>> >> >
>>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>>> >> support
>>>> >> >
>>>> >> >
>>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>>> that
>>>> >> >
>>>> >> >
>>>> >> >     contains the Nvidia libraries / binaries when the docker image
>>>> has
>>>> >> >
>>>> >> >
>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>>> >> >
>>>> >> >
>>>> >> >     containerizer will come in a future release.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>> additional IP
>>>> >> > address
>>>> >> >
>>>> >> >     subject alternative name extension verification.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The CHANGELOG for the release is available at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>> >> >
>>>> >> >
>>>> >>
>>>> --------------------------------------------------------------------------------
>>>> >> >
>>>> >> >
>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>> >> >
>>>> >> >
>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>> >> >
>>>> >> >
>>>> >> > The MD5 checksum of the tarball can be found at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>> >> >
>>>> >> >
>>>> >> > The signature of the tarball can be found at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>> >> >
>>>> >> >
>>>> >> > The PGP key used to sign the release is here:
>>>> >> >
>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>> >> >
>>>> >> >
>>>> >> > The JAR is up in Maven in a staging repository here:
>>>> >> >
>>>> >> >
>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>> >> >
>>>> >> >
>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>> >> >
>>>> >> >
>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>> >> >
>>>> >> >
>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>> >> >
>>>> >> > [ ] -1 Do not release this package because ...
>>>> >> >
>>>> >> >
>>>> >> > Thanks,
>>>> >> >
>>>> >> > Vinod
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Cheers,
>>>> >
>>>> > Zhitao Li
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>


-- 
Best Regards,
Haosdent Huang

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[haosdent <ha...@gmail.com>]

+1

Tested on CentOS 7.

- sudo make check
- upgrade from 0.28.2 to 1.0.0-rc2

On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov <al...@mesosphere.com> wrote:

> Haosdent investigated the issue, and it seems that health checks do work
> for docker executor. Hence I retract my negative vote.
>
> On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> -1 (binding): MESOS-5848
>> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the
>> way.
>>
>> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:
>>
>>> +1 (nonbinding)
>>>
>>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and
>>> downgrade on a small test cluster for both master and slave.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>>
>>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>>> build
>>>> will be 1.0.0. Sorry for the confusion.
>>>>
>>>> Kapil
>>>>
>>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi Kapil,
>>>> >
>>>> > Do you mean that the stable builds from
>>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>>> configuration?
>>>> >
>>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>>> wrote:
>>>> >
>>>> >> The binary rpm/deb packages can be found here:
>>>> >>
>>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>>> >> .
>>>> >>
>>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>>> >> module dependency installation. Here is the configure command line:
>>>> >>     ./configure --enable-libevent --enable-ssl
>>>> >> --enable-install-module-dependencies
>>>> >>
>>>> >> As always, the stable builds are available at:
>>>> >>     http://open.mesosphere.com/downloads/mesos
>>>> >>
>>>> >> The instructions for nightly builds are available at:
>>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>>> >>
>>>> >> Best,
>>>> >> Kapil
>>>> >>
>>>> >>
>>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>>> wrote:
>>>> >> >
>>>> >> > Hi all,
>>>> >> >
>>>> >> >
>>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>>> 1.0.0.
>>>> >> >
>>>> >> >
>>>> >> > 1.0.0 includes the following:
>>>> >> >
>>>> >> >
>>>> >>
>>>> --------------------------------------------------------------------------------
>>>> >> >
>>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>>>> >> APIs.
>>>> >> > These
>>>> >> >
>>>> >> >     APIs let operators and services (monitoring, load balancers)
>>>> send
>>>> >> HTTP
>>>> >> >
>>>> >> >
>>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>>> >> >
>>>> >> >
>>>> >> >     `docs/operator-http-api.md` for details.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>>> >> isolator
>>>> >> >
>>>> >> >
>>>> >> >     has been added to isolate disk resources more efficiently.
>>>> Please
>>>> >> refer
>>>> >> > to
>>>> >> >
>>>> >> >     docs/mesos-containerizer.md for more details.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>>> plugin. We
>>>> >> > added a
>>>> >> >
>>>> >> >     new isolator 'docker/volume' which allows users to use external
>>>> >> volumes
>>>> >> > in
>>>> >> >
>>>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>>>> >> Docker
>>>> >> >
>>>> >> >
>>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>>> Docker
>>>> >> > volume
>>>> >> >
>>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>> >> >
>>>> >> >
>>>> >> >     `network/cni` isolator, has been introduced in the
>>>> >> > `MesosContainerizer`. The
>>>> >> >
>>>> >> >     `network/cni` isolator implements the Container Network
>>>> Interface
>>>> >> (CNI)
>>>> >> >
>>>> >> >
>>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>>> >> isolator
>>>> >> > is
>>>> >> >
>>>> >> >     able to allocate a network namespace to Mesos containers and
>>>> attach
>>>> >> the
>>>> >> >
>>>> >> >
>>>> >> >     container to different types of IP networks by invoking network
>>>> >> drivers
>>>> >> >
>>>> >> >
>>>> >> >     called CNI plugins.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>>> >> refactored
>>>> >> > in
>>>> >> >
>>>> >> >     order to decouple the ACLs definition language from the
>>>> interface.
>>>> >> >
>>>> >> >
>>>> >> >     It additionally includes the option of retrieving
>>>> `ObjectApprover`.
>>>> >> An
>>>> >> >
>>>> >> >
>>>> >> >     `ObjectApprover` can be used to synchronously check
>>>> authorizations
>>>> >> for
>>>> >> > a
>>>> >> >
>>>> >> >     given object and is hence useful when authorizing a large
>>>> number of
>>>> >> > objects
>>>> >> >
>>>> >> >     and/or large objects (which need to be copied using request
>>>> based
>>>> >> >
>>>> >> >
>>>> >> >     authorization). NOTE: This is a **breaking change** for
>>>> authorizer
>>>> >> > modules.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>>> >> > authorization::Request
>>>> >> >
>>>> >> >     have been changed from required to optional. If either of these
>>>> >> fields
>>>> >> > is
>>>> >> >
>>>> >> >     not set, the request should only be authorized if any
>>>> subject/object
>>>> >> > should
>>>> >> >
>>>> >> >     be allowed.
>>>> >> >
>>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>>>> >> > endpoint
>>>> >> >
>>>> >> >     filtering enables operators to restrict what part of the
>>>> cluster
>>>> >> state
>>>> >> > a
>>>> >> >
>>>> >> >     user is authorized to see.
>>>> >> >
>>>> >> >
>>>> >> >     Consider for example the `/state` master endpoint: an operator
>>>> can
>>>> >> now
>>>> >> >
>>>> >> >
>>>> >> >     authorize users to only see a subset of the running frameworks,
>>>> >> tasks,
>>>> >> > or
>>>> >> >
>>>> >> >     executors. The following endpoints support HTTP endpoint
>>>> filtering:
>>>> >> >
>>>> >> >
>>>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>>>> >> >
>>>> >> >
>>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>>> >> filtering:
>>>> >> >
>>>> >> >
>>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>>> >> > 'GET_TASKS'.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>>> >> > best-effort,
>>>> >> >
>>>> >> >     because machine failures or forcible terminations may occur.
>>>> >> Currently,
>>>> >> > the
>>>> >> >
>>>> >> >     only available kill policy is how long to wait between
>>>> graceful and
>>>> >> > forcible
>>>> >> >
>>>> >> >     task kill. In the future, more policies may be available (e.g.
>>>> >> hitting
>>>> >> > an
>>>> >> >
>>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>>> >> executor's
>>>> >> >
>>>> >> >
>>>> >> >     responsibility to enforce kill policies. For executor-less
>>>> >> > command-based
>>>> >> >
>>>> >> >     tasks, the kill is performed via sending a signal to the task
>>>> >> process:
>>>> >> >
>>>> >> >
>>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>>> kill. For
>>>> >> > docker
>>>> >> >
>>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>>> >> --time'.
>>>> >> > This
>>>> >> >
>>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>>> >> > deprecated.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>>> can
>>>> >> now
>>>> >> > be
>>>> >> >
>>>> >> >     overridden when the scheduler kills the task. This can be used
>>>> by
>>>> >> > schedulers
>>>> >> >
>>>> >> >     to forcefully kill a task which is already being killed, e.g.
>>>> if
>>>> >> > something
>>>> >> >
>>>> >> >     went wrong during a graceful kill and a forcible kill is
>>>> desired.
>>>> >> Note
>>>> >> > that
>>>> >> >
>>>> >> >     it is the executor's responsibility to honor the
>>>> >> > 'Event.kill.kill_policy'
>>>> >> >
>>>> >> >     field and override the task's kill policy and kill policy from
>>>> a
>>>> >> > previous
>>>> >> >
>>>> >> >     kill task request. To use this feature, schedulers and
>>>> executors
>>>> >> must
>>>> >> >
>>>> >> >
>>>> >> >     support HTTP API; use the '--http_command_executor' agent flag
>>>> to
>>>> >> > ensure
>>>> >> >
>>>> >> >     the agent launches the HTTP API based command executor.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>>> >> configured
>>>> >> > in
>>>> >> >
>>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>>> down
>>>> >> an
>>>> >> >
>>>> >> >
>>>> >> >     executor the agent will wait in a best-effort manner for the
>>>> grace
>>>> >> > period
>>>> >> >
>>>> >> >     specified here before forcibly destroying the container. The
>>>> >> executor
>>>> >> > must
>>>> >> >
>>>> >> >     not assume that it will always be allotted the full grace
>>>> period, as
>>>> >> > the
>>>> >> >
>>>> >> >     agent may decide to allot a shorter period and failures /
>>>> forcible
>>>> >> >
>>>> >> >
>>>> >> >     terminations may occur. Together with kill policies this gives
>>>> >> > frameworks
>>>> >> >
>>>> >> >     flexibility around how to clean up tasks and executors.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>>> tasks on
>>>> >> >
>>>> >> >
>>>> >> >     Windows. Note that there are no isolation guarantees provided
>>>> yet.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>>>> into
>>>> >> > two,
>>>> >> >
>>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also
>>>> removes
>>>> >> >
>>>> >> >
>>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>>> >> >
>>>> >> >
>>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>>> >> modules
>>>> >> > for
>>>> >> >
>>>> >> >     backwards compatibility with existing code.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>>> complete. To
>>>> >> > support
>>>> >> >
>>>> >> >     the rename, new duplicate flags (e.g.,
>>>> --agent_reregister_timeout),
>>>> >> new
>>>> >> >
>>>> >> >
>>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>>> >> added.
>>>> >> > All
>>>> >> >
>>>> >> >     the logging output has been updated to use the term 'agent'
>>>> now.
>>>> >> Flags,
>>>> >> >
>>>> >> >
>>>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>>>> (see
>>>> >> >
>>>> >> >
>>>> >> >     "Deprecations section below").
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4312] - **Experimental** support for building and
>>>> running
>>>> >> mesos
>>>> >> > on
>>>> >> >
>>>> >> >     IBM PowerPC platform.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>>>> >> > dynamically
>>>> >> >
>>>> >> >     via the new '/weights' endpoint on the master.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>>> the
>>>> >> >
>>>> >> >
>>>> >> >     Mesos "unified" containerizer. This support includes running
>>>> >> containers
>>>> >> >
>>>> >> >
>>>> >> >     with and without filesystem isolation (i.e. running both
>>>> imageless
>>>> >> >
>>>> >> >
>>>> >> >     containers as well as containers using a docker image).
>>>> Frameworks
>>>> >> must
>>>> >> >
>>>> >> >
>>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>>> framework
>>>> >> >
>>>> >> >
>>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>>> >> support
>>>> >> >
>>>> >> >
>>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>>> that
>>>> >> >
>>>> >> >
>>>> >> >     contains the Nvidia libraries / binaries when the docker image
>>>> has
>>>> >> >
>>>> >> >
>>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>>> >> >
>>>> >> >
>>>> >> >     containerizer will come in a future release.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >   * [MESOS-5724] - SSL certificate validation allows for
>>>> additional IP
>>>> >> > address
>>>> >> >
>>>> >> >     subject alternative name extension verification.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The CHANGELOG for the release is available at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>>> >> >
>>>> >> >
>>>> >>
>>>> --------------------------------------------------------------------------------
>>>> >> >
>>>> >> >
>>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>>> >> >
>>>> >> >
>>>> >> > The tag to be voted on is 1.0.0-rc2:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>>> >> >
>>>> >> >
>>>> >> > The MD5 checksum of the tarball can be found at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>>> >> >
>>>> >> >
>>>> >> > The signature of the tarball can be found at:
>>>> >> >
>>>> >> >
>>>> >>
>>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>>> >> >
>>>> >> >
>>>> >> > The PGP key used to sign the release is here:
>>>> >> >
>>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>> >> >
>>>> >> >
>>>> >> > The JAR is up in Maven in a staging repository here:
>>>> >> >
>>>> >> >
>>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>>> >> >
>>>> >> >
>>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>>> >> >
>>>> >> >
>>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>>>> >> > majority of at least 3 +1 PMC votes are cast.
>>>> >> >
>>>> >> >
>>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>>> >> >
>>>> >> > [ ] -1 Do not release this package because ...
>>>> >> >
>>>> >> >
>>>> >> > Thanks,
>>>> >> >
>>>> >> > Vinod
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Cheers,
>>>> >
>>>> > Zhitao Li
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>


-- 
Best Regards,
Haosdent Huang

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Alex Rukletsov <al...@mesosphere.com>]

Haosdent investigated the issue, and it seems that health checks do work
for docker executor. Hence I retract my negative vote.

On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
wrote:

> -1 (binding): MESOS-5848
> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the way.
>
> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:
>
>> +1 (nonbinding)
>>
>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
>> on a small test cluster for both master and slave.
>>
>>
>>
>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>> build
>>> will be 1.0.0. Sorry for the confusion.
>>>
>>> Kapil
>>>
>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>> > Hi Kapil,
>>> >
>>> > Do you mean that the stable builds from
>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>> configuration?
>>> >
>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>> >
>>> >> The binary rpm/deb packages can be found here:
>>> >>
>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>> >> .
>>> >>
>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>> >> module dependency installation. Here is the configure command line:
>>> >>     ./configure --enable-libevent --enable-ssl
>>> >> --enable-install-module-dependencies
>>> >>
>>> >> As always, the stable builds are available at:
>>> >>     http://open.mesosphere.com/downloads/mesos
>>> >>
>>> >> The instructions for nightly builds are available at:
>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>> >>
>>> >> Best,
>>> >> Kapil
>>> >>
>>> >>
>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>> wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> >
>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>> 1.0.0.
>>> >> >
>>> >> >
>>> >> > 1.0.0 includes the following:
>>> >> >
>>> >> >
>>> >>
>>> --------------------------------------------------------------------------------
>>> >> >
>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>>> >> APIs.
>>> >> > These
>>> >> >
>>> >> >     APIs let operators and services (monitoring, load balancers)
>>> send
>>> >> HTTP
>>> >> >
>>> >> >
>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>> >> >
>>> >> >
>>> >> >     `docs/operator-http-api.md` for details.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>> >> isolator
>>> >> >
>>> >> >
>>> >> >     has been added to isolate disk resources more efficiently.
>>> Please
>>> >> refer
>>> >> > to
>>> >> >
>>> >> >     docs/mesos-containerizer.md for more details.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>> plugin. We
>>> >> > added a
>>> >> >
>>> >> >     new isolator 'docker/volume' which allows users to use external
>>> >> volumes
>>> >> > in
>>> >> >
>>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>>> >> Docker
>>> >> >
>>> >> >
>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>> Docker
>>> >> > volume
>>> >> >
>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>> >> >
>>> >> >
>>> >> >     `network/cni` isolator, has been introduced in the
>>> >> > `MesosContainerizer`. The
>>> >> >
>>> >> >     `network/cni` isolator implements the Container Network
>>> Interface
>>> >> (CNI)
>>> >> >
>>> >> >
>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>> >> isolator
>>> >> > is
>>> >> >
>>> >> >     able to allocate a network namespace to Mesos containers and
>>> attach
>>> >> the
>>> >> >
>>> >> >
>>> >> >     container to different types of IP networks by invoking network
>>> >> drivers
>>> >> >
>>> >> >
>>> >> >     called CNI plugins.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>> >> refactored
>>> >> > in
>>> >> >
>>> >> >     order to decouple the ACLs definition language from the
>>> interface.
>>> >> >
>>> >> >
>>> >> >     It additionally includes the option of retrieving
>>> `ObjectApprover`.
>>> >> An
>>> >> >
>>> >> >
>>> >> >     `ObjectApprover` can be used to synchronously check
>>> authorizations
>>> >> for
>>> >> > a
>>> >> >
>>> >> >     given object and is hence useful when authorizing a large
>>> number of
>>> >> > objects
>>> >> >
>>> >> >     and/or large objects (which need to be copied using request
>>> based
>>> >> >
>>> >> >
>>> >> >     authorization). NOTE: This is a **breaking change** for
>>> authorizer
>>> >> > modules.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>> >> > authorization::Request
>>> >> >
>>> >> >     have been changed from required to optional. If either of these
>>> >> fields
>>> >> > is
>>> >> >
>>> >> >     not set, the request should only be authorized if any
>>> subject/object
>>> >> > should
>>> >> >
>>> >> >     be allowed.
>>> >> >
>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>>> >> > endpoint
>>> >> >
>>> >> >     filtering enables operators to restrict what part of the cluster
>>> >> state
>>> >> > a
>>> >> >
>>> >> >     user is authorized to see.
>>> >> >
>>> >> >
>>> >> >     Consider for example the `/state` master endpoint: an operator
>>> can
>>> >> now
>>> >> >
>>> >> >
>>> >> >     authorize users to only see a subset of the running frameworks,
>>> >> tasks,
>>> >> > or
>>> >> >
>>> >> >     executors. The following endpoints support HTTP endpoint
>>> filtering:
>>> >> >
>>> >> >
>>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>>> >> >
>>> >> >
>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>> >> filtering:
>>> >> >
>>> >> >
>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>> >> > 'GET_TASKS'.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>> >> > best-effort,
>>> >> >
>>> >> >     because machine failures or forcible terminations may occur.
>>> >> Currently,
>>> >> > the
>>> >> >
>>> >> >     only available kill policy is how long to wait between graceful
>>> and
>>> >> > forcible
>>> >> >
>>> >> >     task kill. In the future, more policies may be available (e.g.
>>> >> hitting
>>> >> > an
>>> >> >
>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>> >> executor's
>>> >> >
>>> >> >
>>> >> >     responsibility to enforce kill policies. For executor-less
>>> >> > command-based
>>> >> >
>>> >> >     tasks, the kill is performed via sending a signal to the task
>>> >> process:
>>> >> >
>>> >> >
>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>> kill. For
>>> >> > docker
>>> >> >
>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>> >> --time'.
>>> >> > This
>>> >> >
>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>> >> > deprecated.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>> can
>>> >> now
>>> >> > be
>>> >> >
>>> >> >     overridden when the scheduler kills the task. This can be used
>>> by
>>> >> > schedulers
>>> >> >
>>> >> >     to forcefully kill a task which is already being killed, e.g. if
>>> >> > something
>>> >> >
>>> >> >     went wrong during a graceful kill and a forcible kill is
>>> desired.
>>> >> Note
>>> >> > that
>>> >> >
>>> >> >     it is the executor's responsibility to honor the
>>> >> > 'Event.kill.kill_policy'
>>> >> >
>>> >> >     field and override the task's kill policy and kill policy from a
>>> >> > previous
>>> >> >
>>> >> >     kill task request. To use this feature, schedulers and executors
>>> >> must
>>> >> >
>>> >> >
>>> >> >     support HTTP API; use the '--http_command_executor' agent flag
>>> to
>>> >> > ensure
>>> >> >
>>> >> >     the agent launches the HTTP API based command executor.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>> >> configured
>>> >> > in
>>> >> >
>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>> down
>>> >> an
>>> >> >
>>> >> >
>>> >> >     executor the agent will wait in a best-effort manner for the
>>> grace
>>> >> > period
>>> >> >
>>> >> >     specified here before forcibly destroying the container. The
>>> >> executor
>>> >> > must
>>> >> >
>>> >> >     not assume that it will always be allotted the full grace
>>> period, as
>>> >> > the
>>> >> >
>>> >> >     agent may decide to allot a shorter period and failures /
>>> forcible
>>> >> >
>>> >> >
>>> >> >     terminations may occur. Together with kill policies this gives
>>> >> > frameworks
>>> >> >
>>> >> >     flexibility around how to clean up tasks and executors.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>> tasks on
>>> >> >
>>> >> >
>>> >> >     Windows. Note that there are no isolation guarantees provided
>>> yet.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>>> into
>>> >> > two,
>>> >> >
>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>>> >> >
>>> >> >
>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>> >> >
>>> >> >
>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>> >> modules
>>> >> > for
>>> >> >
>>> >> >     backwards compatibility with existing code.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>> complete. To
>>> >> > support
>>> >> >
>>> >> >     the rename, new duplicate flags (e.g.,
>>> --agent_reregister_timeout),
>>> >> new
>>> >> >
>>> >> >
>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>> >> added.
>>> >> > All
>>> >> >
>>> >> >     the logging output has been updated to use the term 'agent' now.
>>> >> Flags,
>>> >> >
>>> >> >
>>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>>> (see
>>> >> >
>>> >> >
>>> >> >     "Deprecations section below").
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4312] - **Experimental** support for building and running
>>> >> mesos
>>> >> > on
>>> >> >
>>> >> >     IBM PowerPC platform.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>>> >> > dynamically
>>> >> >
>>> >> >     via the new '/weights' endpoint on the master.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>> the
>>> >> >
>>> >> >
>>> >> >     Mesos "unified" containerizer. This support includes running
>>> >> containers
>>> >> >
>>> >> >
>>> >> >     with and without filesystem isolation (i.e. running both
>>> imageless
>>> >> >
>>> >> >
>>> >> >     containers as well as containers using a docker image).
>>> Frameworks
>>> >> must
>>> >> >
>>> >> >
>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>> framework
>>> >> >
>>> >> >
>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>> >> support
>>> >> >
>>> >> >
>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>> that
>>> >> >
>>> >> >
>>> >> >     contains the Nvidia libraries / binaries when the docker image
>>> has
>>> >> >
>>> >> >
>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>> >> >
>>> >> >
>>> >> >     containerizer will come in a future release.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-5724] - SSL certificate validation allows for additional
>>> IP
>>> >> > address
>>> >> >
>>> >> >     subject alternative name extension verification.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > The CHANGELOG for the release is available at:
>>> >> >
>>> >> >
>>> >>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>> >> >
>>> >> >
>>> >>
>>> --------------------------------------------------------------------------------
>>> >> >
>>> >> >
>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>> >> >
>>> >> >
>>> >> > The tag to be voted on is 1.0.0-rc2:
>>> >> >
>>> >> >
>>> >>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>> >> >
>>> >> >
>>> >> > The MD5 checksum of the tarball can be found at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>> >> >
>>> >> >
>>> >> > The signature of the tarball can be found at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>> >> >
>>> >> >
>>> >> > The PGP key used to sign the release is here:
>>> >> >
>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>> >> >
>>> >> >
>>> >> > The JAR is up in Maven in a staging repository here:
>>> >> >
>>> >> >
>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>> >> >
>>> >> >
>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>> >> >
>>> >> >
>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>>> >> > majority of at least 3 +1 PMC votes are cast.
>>> >> >
>>> >> >
>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>> >> >
>>> >> > [ ] -1 Do not release this package because ...
>>> >> >
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > Vinod
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> >
>>> > Zhitao Li
>>> >
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Alex Rukletsov <al...@mesosphere.com>]

Haosdent investigated the issue, and it seems that health checks do work
for docker executor. Hence I retract my negative vote.

On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <al...@mesosphere.com>
wrote:

> -1 (binding): MESOS-5848
> <https://issues.apache.org/jira/browse/MESOS-5848>. The fix is on the way.
>
> On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:
>
>> +1 (nonbinding)
>>
>> Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
>> on a small test cluster for both master and slave.
>>
>>
>>
>> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>>> None of the stable builds have SSL yet. The first SSL-enabled stable
>>> build
>>> will be 1.0.0. Sorry for the confusion.
>>>
>>> Kapil
>>>
>>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com>
>>> wrote:
>>>
>>> > Hi Kapil,
>>> >
>>> > Do you mean that the stable builds from
>>> > http://open.mesosphere.com/downloads/mesos is using the new
>>> configuration?
>>> >
>>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>>> wrote:
>>> >
>>> >> The binary rpm/deb packages can be found here:
>>> >>
>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>>> >> .
>>> >>
>>> >> Please note that starting with the 1.0.0 release (including RCs and
>>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>>> >> module dependency installation. Here is the configure command line:
>>> >>     ./configure --enable-libevent --enable-ssl
>>> >> --enable-install-module-dependencies
>>> >>
>>> >> As always, the stable builds are available at:
>>> >>     http://open.mesosphere.com/downloads/mesos
>>> >>
>>> >> The instructions for nightly builds are available at:
>>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>>> >>
>>> >> Best,
>>> >> Kapil
>>> >>
>>> >>
>>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>>> wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> >
>>> >> > Please vote on releasing the following candidate as Apache Mesos
>>> 1.0.0.
>>> >> >
>>> >> >
>>> >> > 1.0.0 includes the following:
>>> >> >
>>> >> >
>>> >>
>>> --------------------------------------------------------------------------------
>>> >> >
>>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>>> >> APIs.
>>> >> > These
>>> >> >
>>> >> >     APIs let operators and services (monitoring, load balancers)
>>> send
>>> >> HTTP
>>> >> >
>>> >> >
>>> >> >     requests to '/api/v1' endpoint on master or agent. See
>>> >> >
>>> >> >
>>> >> >     `docs/operator-http-api.md` for details.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>> >> isolator
>>> >> >
>>> >> >
>>> >> >     has been added to isolate disk resources more efficiently.
>>> Please
>>> >> refer
>>> >> > to
>>> >> >
>>> >> >     docs/mesos-containerizer.md for more details.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>>> plugin. We
>>> >> > added a
>>> >> >
>>> >> >     new isolator 'docker/volume' which allows users to use external
>>> >> volumes
>>> >> > in
>>> >> >
>>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>>> >> Docker
>>> >> >
>>> >> >
>>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>>> Docker
>>> >> > volume
>>> >> >
>>> >> >     plugin API, most of the Docker volume plugins are supported.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>>> >> >
>>> >> >
>>> >> >     `network/cni` isolator, has been introduced in the
>>> >> > `MesosContainerizer`. The
>>> >> >
>>> >> >     `network/cni` isolator implements the Container Network
>>> Interface
>>> >> (CNI)
>>> >> >
>>> >> >
>>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>>> >> isolator
>>> >> > is
>>> >> >
>>> >> >     able to allocate a network namespace to Mesos containers and
>>> attach
>>> >> the
>>> >> >
>>> >> >
>>> >> >     container to different types of IP networks by invoking network
>>> >> drivers
>>> >> >
>>> >> >
>>> >> >     called CNI plugins.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>>> >> refactored
>>> >> > in
>>> >> >
>>> >> >     order to decouple the ACLs definition language from the
>>> interface.
>>> >> >
>>> >> >
>>> >> >     It additionally includes the option of retrieving
>>> `ObjectApprover`.
>>> >> An
>>> >> >
>>> >> >
>>> >> >     `ObjectApprover` can be used to synchronously check
>>> authorizations
>>> >> for
>>> >> > a
>>> >> >
>>> >> >     given object and is hence useful when authorizing a large
>>> number of
>>> >> > objects
>>> >> >
>>> >> >     and/or large objects (which need to be copied using request
>>> based
>>> >> >
>>> >> >
>>> >> >     authorization). NOTE: This is a **breaking change** for
>>> authorizer
>>> >> > modules.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>>> >> > authorization::Request
>>> >> >
>>> >> >     have been changed from required to optional. If either of these
>>> >> fields
>>> >> > is
>>> >> >
>>> >> >     not set, the request should only be authorized if any
>>> subject/object
>>> >> > should
>>> >> >
>>> >> >     be allowed.
>>> >> >
>>> >> >     NOTE: This is a semantic change for authorizer modules.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>>> >> > endpoint
>>> >> >
>>> >> >     filtering enables operators to restrict what part of the cluster
>>> >> state
>>> >> > a
>>> >> >
>>> >> >     user is authorized to see.
>>> >> >
>>> >> >
>>> >> >     Consider for example the `/state` master endpoint: an operator
>>> can
>>> >> now
>>> >> >
>>> >> >
>>> >> >     authorize users to only see a subset of the running frameworks,
>>> >> tasks,
>>> >> > or
>>> >> >
>>> >> >     executors. The following endpoints support HTTP endpoint
>>> filtering:
>>> >> >
>>> >> >
>>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>>> >> >
>>> >> >
>>> >> >     and '/roles'. Additonally the following v1 API calls support
>>> >> filtering:
>>> >> >
>>> >> >
>>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>>> >> > 'GET_TASKS'.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>>> >> > best-effort,
>>> >> >
>>> >> >     because machine failures or forcible terminations may occur.
>>> >> Currently,
>>> >> > the
>>> >> >
>>> >> >     only available kill policy is how long to wait between graceful
>>> and
>>> >> > forcible
>>> >> >
>>> >> >     task kill. In the future, more policies may be available (e.g.
>>> >> hitting
>>> >> > an
>>> >> >
>>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>>> >> executor's
>>> >> >
>>> >> >
>>> >> >     responsibility to enforce kill policies. For executor-less
>>> >> > command-based
>>> >> >
>>> >> >     tasks, the kill is performed via sending a signal to the task
>>> >> process:
>>> >> >
>>> >> >
>>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible
>>> kill. For
>>> >> > docker
>>> >> >
>>> >> >     executor-less tasks the grace period is passed to 'docker stop
>>> >> --time'.
>>> >> > This
>>> >> >
>>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>>> >> > deprecated.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo'
>>> can
>>> >> now
>>> >> > be
>>> >> >
>>> >> >     overridden when the scheduler kills the task. This can be used
>>> by
>>> >> > schedulers
>>> >> >
>>> >> >     to forcefully kill a task which is already being killed, e.g. if
>>> >> > something
>>> >> >
>>> >> >     went wrong during a graceful kill and a forcible kill is
>>> desired.
>>> >> Note
>>> >> > that
>>> >> >
>>> >> >     it is the executor's responsibility to honor the
>>> >> > 'Event.kill.kill_policy'
>>> >> >
>>> >> >     field and override the task's kill policy and kill policy from a
>>> >> > previous
>>> >> >
>>> >> >     kill task request. To use this feature, schedulers and executors
>>> >> must
>>> >> >
>>> >> >
>>> >> >     support HTTP API; use the '--http_command_executor' agent flag
>>> to
>>> >> > ensure
>>> >> >
>>> >> >     the agent launches the HTTP API based command executor.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>>> >> configured
>>> >> > in
>>> >> >
>>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>>> down
>>> >> an
>>> >> >
>>> >> >
>>> >> >     executor the agent will wait in a best-effort manner for the
>>> grace
>>> >> > period
>>> >> >
>>> >> >     specified here before forcibly destroying the container. The
>>> >> executor
>>> >> > must
>>> >> >
>>> >> >     not assume that it will always be allotted the full grace
>>> period, as
>>> >> > the
>>> >> >
>>> >> >     agent may decide to allot a shorter period and failures /
>>> forcible
>>> >> >
>>> >> >
>>> >> >     terminations may occur. Together with kill policies this gives
>>> >> > frameworks
>>> >> >
>>> >> >     flexibility around how to clean up tasks and executors.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>>> tasks on
>>> >> >
>>> >> >
>>> >> >     Windows. Note that there are no isolation guarantees provided
>>> yet.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>>> into
>>> >> > two,
>>> >> >
>>> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>>> >> >
>>> >> >
>>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>>> >> >
>>> >> >
>>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>>> >> modules
>>> >> > for
>>> >> >
>>> >> >     backwards compatibility with existing code.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is
>>> complete. To
>>> >> > support
>>> >> >
>>> >> >     the rename, new duplicate flags (e.g.,
>>> --agent_reregister_timeout),
>>> >> new
>>> >> >
>>> >> >
>>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>>> >> added.
>>> >> > All
>>> >> >
>>> >> >     the logging output has been updated to use the term 'agent' now.
>>> >> Flags,
>>> >> >
>>> >> >
>>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>>> (see
>>> >> >
>>> >> >
>>> >> >     "Deprecations section below").
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4312] - **Experimental** support for building and running
>>> >> mesos
>>> >> > on
>>> >> >
>>> >> >     IBM PowerPC platform.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>>> >> > dynamically
>>> >> >
>>> >> >     via the new '/weights' endpoint on the master.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in
>>> the
>>> >> >
>>> >> >
>>> >> >     Mesos "unified" containerizer. This support includes running
>>> >> containers
>>> >> >
>>> >> >
>>> >> >     with and without filesystem isolation (i.e. running both
>>> imageless
>>> >> >
>>> >> >
>>> >> >     containers as well as containers using a docker image).
>>> Frameworks
>>> >> must
>>> >> >
>>> >> >
>>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES
>>> framework
>>> >> >
>>> >> >
>>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>>> >> support
>>> >> >
>>> >> >
>>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>>> that
>>> >> >
>>> >> >
>>> >> >     contains the Nvidia libraries / binaries when the docker image
>>> has
>>> >> >
>>> >> >
>>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>>> >> >
>>> >> >
>>> >> >     containerizer will come in a future release.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >   * [MESOS-5724] - SSL certificate validation allows for additional
>>> IP
>>> >> > address
>>> >> >
>>> >> >     subject alternative name extension verification.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > The CHANGELOG for the release is available at:
>>> >> >
>>> >> >
>>> >>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>>> >> >
>>> >> >
>>> >>
>>> --------------------------------------------------------------------------------
>>> >> >
>>> >> >
>>> >> > The candidate for Mesos 1.0.0 release is available at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>>> >> >
>>> >> >
>>> >> > The tag to be voted on is 1.0.0-rc2:
>>> >> >
>>> >> >
>>> >>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>>> >> >
>>> >> >
>>> >> > The MD5 checksum of the tarball can be found at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>>> >> >
>>> >> >
>>> >> > The signature of the tarball can be found at:
>>> >> >
>>> >> >
>>> >>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>>> >> >
>>> >> >
>>> >> > The PGP key used to sign the release is here:
>>> >> >
>>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>> >> >
>>> >> >
>>> >> > The JAR is up in Maven in a staging repository here:
>>> >> >
>>> >> >
>>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>>> >> >
>>> >> >
>>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>>> >> >
>>> >> >
>>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>>> >> > majority of at least 3 +1 PMC votes are cast.
>>> >> >
>>> >> >
>>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>>> >> >
>>> >> > [ ] -1 Do not release this package because ...
>>> >> >
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > Vinod
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> >
>>> > Zhitao Li
>>> >
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Alex Rukletsov <al...@mesosphere.com>]

-1 (binding): MESOS-5848 <https://issues.apache.org/jira/browse/MESOS-5848>.
The fix is on the way.

On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:

> +1 (nonbinding)
>
> Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
> on a small test cluster for both master and slave.
>
>
>
> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> None of the stable builds have SSL yet. The first SSL-enabled stable build
>> will be 1.0.0. Sorry for the confusion.
>>
>> Kapil
>>
>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> > Hi Kapil,
>> >
>> > Do you mean that the stable builds from
>> > http://open.mesosphere.com/downloads/mesos is using the new
>> configuration?
>> >
>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >
>> >> The binary rpm/deb packages can be found here:
>> >>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>> >> .
>> >>
>> >> Please note that starting with the 1.0.0 release (including RCs and
>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>> >> module dependency installation. Here is the configure command line:
>> >>     ./configure --enable-libevent --enable-ssl
>> >> --enable-install-module-dependencies
>> >>
>> >> As always, the stable builds are available at:
>> >>     http://open.mesosphere.com/downloads/mesos
>> >>
>> >> The instructions for nightly builds are available at:
>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>> >>
>> >> Best,
>> >> Kapil
>> >>
>> >>
>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> >
>> >> > Please vote on releasing the following candidate as Apache Mesos
>> 1.0.0.
>> >> >
>> >> >
>> >> > 1.0.0 includes the following:
>> >> >
>> >> >
>> >>
>> --------------------------------------------------------------------------------
>> >> >
>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> >> APIs.
>> >> > These
>> >> >
>> >> >     APIs let operators and services (monitoring, load balancers) send
>> >> HTTP
>> >> >
>> >> >
>> >> >     requests to '/api/v1' endpoint on master or agent. See
>> >> >
>> >> >
>> >> >     `docs/operator-http-api.md` for details.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> >> isolator
>> >> >
>> >> >
>> >> >     has been added to isolate disk resources more efficiently. Please
>> >> refer
>> >> > to
>> >> >
>> >> >     docs/mesos-containerizer.md for more details.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>> plugin. We
>> >> > added a
>> >> >
>> >> >     new isolator 'docker/volume' which allows users to use external
>> >> volumes
>> >> > in
>> >> >
>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>> >> Docker
>> >> >
>> >> >
>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>> Docker
>> >> > volume
>> >> >
>> >> >     plugin API, most of the Docker volume plugins are supported.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>> >> >
>> >> >
>> >> >     `network/cni` isolator, has been introduced in the
>> >> > `MesosContainerizer`. The
>> >> >
>> >> >     `network/cni` isolator implements the Container Network Interface
>> >> (CNI)
>> >> >
>> >> >
>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>> >> isolator
>> >> > is
>> >> >
>> >> >     able to allocate a network namespace to Mesos containers and
>> attach
>> >> the
>> >> >
>> >> >
>> >> >     container to different types of IP networks by invoking network
>> >> drivers
>> >> >
>> >> >
>> >> >     called CNI plugins.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>> >> refactored
>> >> > in
>> >> >
>> >> >     order to decouple the ACLs definition language from the
>> interface.
>> >> >
>> >> >
>> >> >     It additionally includes the option of retrieving
>> `ObjectApprover`.
>> >> An
>> >> >
>> >> >
>> >> >     `ObjectApprover` can be used to synchronously check
>> authorizations
>> >> for
>> >> > a
>> >> >
>> >> >     given object and is hence useful when authorizing a large number
>> of
>> >> > objects
>> >> >
>> >> >     and/or large objects (which need to be copied using request based
>> >> >
>> >> >
>> >> >     authorization). NOTE: This is a **breaking change** for
>> authorizer
>> >> > modules.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>> >> > authorization::Request
>> >> >
>> >> >     have been changed from required to optional. If either of these
>> >> fields
>> >> > is
>> >> >
>> >> >     not set, the request should only be authorized if any
>> subject/object
>> >> > should
>> >> >
>> >> >     be allowed.
>> >> >
>> >> >     NOTE: This is a semantic change for authorizer modules.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>> >> > endpoint
>> >> >
>> >> >     filtering enables operators to restrict what part of the cluster
>> >> state
>> >> > a
>> >> >
>> >> >     user is authorized to see.
>> >> >
>> >> >
>> >> >     Consider for example the `/state` master endpoint: an operator
>> can
>> >> now
>> >> >
>> >> >
>> >> >     authorize users to only see a subset of the running frameworks,
>> >> tasks,
>> >> > or
>> >> >
>> >> >     executors. The following endpoints support HTTP endpoint
>> filtering:
>> >> >
>> >> >
>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>> >> >
>> >> >
>> >> >     and '/roles'. Additonally the following v1 API calls support
>> >> filtering:
>> >> >
>> >> >
>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>> >> > 'GET_TASKS'.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>> >> > best-effort,
>> >> >
>> >> >     because machine failures or forcible terminations may occur.
>> >> Currently,
>> >> > the
>> >> >
>> >> >     only available kill policy is how long to wait between graceful
>> and
>> >> > forcible
>> >> >
>> >> >     task kill. In the future, more policies may be available (e.g.
>> >> hitting
>> >> > an
>> >> >
>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>> >> executor's
>> >> >
>> >> >
>> >> >     responsibility to enforce kill policies. For executor-less
>> >> > command-based
>> >> >
>> >> >     tasks, the kill is performed via sending a signal to the task
>> >> process:
>> >> >
>> >> >
>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill.
>> For
>> >> > docker
>> >> >
>> >> >     executor-less tasks the grace period is passed to 'docker stop
>> >> --time'.
>> >> > This
>> >> >
>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>> >> > deprecated.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
>> >> now
>> >> > be
>> >> >
>> >> >     overridden when the scheduler kills the task. This can be used by
>> >> > schedulers
>> >> >
>> >> >     to forcefully kill a task which is already being killed, e.g. if
>> >> > something
>> >> >
>> >> >     went wrong during a graceful kill and a forcible kill is desired.
>> >> Note
>> >> > that
>> >> >
>> >> >     it is the executor's responsibility to honor the
>> >> > 'Event.kill.kill_policy'
>> >> >
>> >> >     field and override the task's kill policy and kill policy from a
>> >> > previous
>> >> >
>> >> >     kill task request. To use this feature, schedulers and executors
>> >> must
>> >> >
>> >> >
>> >> >     support HTTP API; use the '--http_command_executor' agent flag to
>> >> > ensure
>> >> >
>> >> >     the agent launches the HTTP API based command executor.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>> >> configured
>> >> > in
>> >> >
>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>> down
>> >> an
>> >> >
>> >> >
>> >> >     executor the agent will wait in a best-effort manner for the
>> grace
>> >> > period
>> >> >
>> >> >     specified here before forcibly destroying the container. The
>> >> executor
>> >> > must
>> >> >
>> >> >     not assume that it will always be allotted the full grace
>> period, as
>> >> > the
>> >> >
>> >> >     agent may decide to allot a shorter period and failures /
>> forcible
>> >> >
>> >> >
>> >> >     terminations may occur. Together with kill policies this gives
>> >> > frameworks
>> >> >
>> >> >     flexibility around how to clean up tasks and executors.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>> tasks on
>> >> >
>> >> >
>> >> >     Windows. Note that there are no isolation guarantees provided
>> yet.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>> into
>> >> > two,
>> >> >
>> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>> >> >
>> >> >
>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>> >> >
>> >> >
>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>> >> modules
>> >> > for
>> >> >
>> >> >     backwards compatibility with existing code.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete.
>> To
>> >> > support
>> >> >
>> >> >     the rename, new duplicate flags (e.g.,
>> --agent_reregister_timeout),
>> >> new
>> >> >
>> >> >
>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>> >> added.
>> >> > All
>> >> >
>> >> >     the logging output has been updated to use the term 'agent' now.
>> >> Flags,
>> >> >
>> >> >
>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>> (see
>> >> >
>> >> >
>> >> >     "Deprecations section below").
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4312] - **Experimental** support for building and running
>> >> mesos
>> >> > on
>> >> >
>> >> >     IBM PowerPC platform.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>> >> > dynamically
>> >> >
>> >> >     via the new '/weights' endpoint on the master.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>> >> >
>> >> >
>> >> >     Mesos "unified" containerizer. This support includes running
>> >> containers
>> >> >
>> >> >
>> >> >     with and without filesystem isolation (i.e. running both
>> imageless
>> >> >
>> >> >
>> >> >     containers as well as containers using a docker image).
>> Frameworks
>> >> must
>> >> >
>> >> >
>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>> >> >
>> >> >
>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>> >> support
>> >> >
>> >> >
>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>> that
>> >> >
>> >> >
>> >> >     contains the Nvidia libraries / binaries when the docker image
>> has
>> >> >
>> >> >
>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>> >> >
>> >> >
>> >> >     containerizer will come in a future release.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-5724] - SSL certificate validation allows for additional
>> IP
>> >> > address
>> >> >
>> >> >     subject alternative name extension verification.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > The CHANGELOG for the release is available at:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>> >> >
>> >> >
>> >>
>> --------------------------------------------------------------------------------
>> >> >
>> >> >
>> >> > The candidate for Mesos 1.0.0 release is available at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>> >> >
>> >> >
>> >> > The tag to be voted on is 1.0.0-rc2:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>> >> >
>> >> >
>> >> > The MD5 checksum of the tarball can be found at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>> >> >
>> >> >
>> >> > The signature of the tarball can be found at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>> >> >
>> >> >
>> >> > The PGP key used to sign the release is here:
>> >> >
>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >> >
>> >> >
>> >> > The JAR is up in Maven in a staging repository here:
>> >> >
>> >> >
>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>> >> >
>> >> >
>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>> >> >
>> >> >
>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>> >> > majority of at least 3 +1 PMC votes are cast.
>> >> >
>> >> >
>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>> >> >
>> >> > [ ] -1 Do not release this package because ...
>> >> >
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Vinod
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> >
>> > Zhitao Li
>> >
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Alex Rukletsov <al...@mesosphere.com>]

-1 (binding): MESOS-5848 <https://issues.apache.org/jira/browse/MESOS-5848>.
The fix is on the way.

On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li <zh...@gmail.com> wrote:

> +1 (nonbinding)
>
> Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
> on a small test cluster for both master and slave.
>
>
>
> On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> None of the stable builds have SSL yet. The first SSL-enabled stable build
>> will be 1.0.0. Sorry for the confusion.
>>
>> Kapil
>>
>> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:
>>
>> > Hi Kapil,
>> >
>> > Do you mean that the stable builds from
>> > http://open.mesosphere.com/downloads/mesos is using the new
>> configuration?
>> >
>> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >
>> >> The binary rpm/deb packages can be found here:
>> >>
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>> >> .
>> >>
>> >> Please note that starting with the 1.0.0 release (including RCs and
>> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
>> >> module dependency installation. Here is the configure command line:
>> >>     ./configure --enable-libevent --enable-ssl
>> >> --enable-install-module-dependencies
>> >>
>> >> As always, the stable builds are available at:
>> >>     http://open.mesosphere.com/downloads/mesos
>> >>
>> >> The instructions for nightly builds are available at:
>> >>     http://open.mesosphere.com/downloads/mesos-nightly/
>> >>
>> >> Best,
>> >> Kapil
>> >>
>> >>
>> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
>> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> >
>> >> > Please vote on releasing the following candidate as Apache Mesos
>> 1.0.0.
>> >> >
>> >> >
>> >> > 1.0.0 includes the following:
>> >> >
>> >> >
>> >>
>> --------------------------------------------------------------------------------
>> >> >
>> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> >> APIs.
>> >> > These
>> >> >
>> >> >     APIs let operators and services (monitoring, load balancers) send
>> >> HTTP
>> >> >
>> >> >
>> >> >     requests to '/api/v1' endpoint on master or agent. See
>> >> >
>> >> >
>> >> >     `docs/operator-http-api.md` for details.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> >> isolator
>> >> >
>> >> >
>> >> >     has been added to isolate disk resources more efficiently. Please
>> >> refer
>> >> > to
>> >> >
>> >> >     docs/mesos-containerizer.md for more details.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4355] - **Experimental** support for Docker volume
>> plugin. We
>> >> > added a
>> >> >
>> >> >     new isolator 'docker/volume' which allows users to use external
>> >> volumes
>> >> > in
>> >> >
>> >> >     Mesos containerizer. Currently, the isolator interacts with the
>> >> Docker
>> >> >
>> >> >
>> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
>> Docker
>> >> > volume
>> >> >
>> >> >     plugin API, most of the Docker volume plugins are supported.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>> >> >
>> >> >
>> >> >     `network/cni` isolator, has been introduced in the
>> >> > `MesosContainerizer`. The
>> >> >
>> >> >     `network/cni` isolator implements the Container Network Interface
>> >> (CNI)
>> >> >
>> >> >
>> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
>> >> isolator
>> >> > is
>> >> >
>> >> >     able to allocate a network namespace to Mesos containers and
>> attach
>> >> the
>> >> >
>> >> >
>> >> >     container to different types of IP networks by invoking network
>> >> drivers
>> >> >
>> >> >
>> >> >     called CNI plugins.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>> >> refactored
>> >> > in
>> >> >
>> >> >     order to decouple the ACLs definition language from the
>> interface.
>> >> >
>> >> >
>> >> >     It additionally includes the option of retrieving
>> `ObjectApprover`.
>> >> An
>> >> >
>> >> >
>> >> >     `ObjectApprover` can be used to synchronously check
>> authorizations
>> >> for
>> >> > a
>> >> >
>> >> >     given object and is hence useful when authorizing a large number
>> of
>> >> > objects
>> >> >
>> >> >     and/or large objects (which need to be copied using request based
>> >> >
>> >> >
>> >> >     authorization). NOTE: This is a **breaking change** for
>> authorizer
>> >> > modules.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-5405] - The `subject` and `object` fields in
>> >> > authorization::Request
>> >> >
>> >> >     have been changed from required to optional. If either of these
>> >> fields
>> >> > is
>> >> >
>> >> >     not set, the request should only be authorized if any
>> subject/object
>> >> > should
>> >> >
>> >> >     be allowed.
>> >> >
>> >> >     NOTE: This is a semantic change for authorizer modules.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>> >> > endpoint
>> >> >
>> >> >     filtering enables operators to restrict what part of the cluster
>> >> state
>> >> > a
>> >> >
>> >> >     user is authorized to see.
>> >> >
>> >> >
>> >> >     Consider for example the `/state` master endpoint: an operator
>> can
>> >> now
>> >> >
>> >> >
>> >> >     authorize users to only see a subset of the running frameworks,
>> >> tasks,
>> >> > or
>> >> >
>> >> >     executors. The following endpoints support HTTP endpoint
>> filtering:
>> >> >
>> >> >
>> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>> >> >
>> >> >
>> >> >     and '/roles'. Additonally the following v1 API calls support
>> >> filtering:
>> >> >
>> >> >
>> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>> >> > 'GET_TASKS'.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>> >> > best-effort,
>> >> >
>> >> >     because machine failures or forcible terminations may occur.
>> >> Currently,
>> >> > the
>> >> >
>> >> >     only available kill policy is how long to wait between graceful
>> and
>> >> > forcible
>> >> >
>> >> >     task kill. In the future, more policies may be available (e.g.
>> >> hitting
>> >> > an
>> >> >
>> >> >     HTTP endpoint, running a command, etc). Note that it is the
>> >> executor's
>> >> >
>> >> >
>> >> >     responsibility to enforce kill policies. For executor-less
>> >> > command-based
>> >> >
>> >> >     tasks, the kill is performed via sending a signal to the task
>> >> process:
>> >> >
>> >> >
>> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill.
>> For
>> >> > docker
>> >> >
>> >> >     executor-less tasks the grace period is passed to 'docker stop
>> >> --time'.
>> >> > This
>> >> >
>> >> >     feature supersedes the '--docker_stop_timeout', which is now
>> >> > deprecated.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
>> >> now
>> >> > be
>> >> >
>> >> >     overridden when the scheduler kills the task. This can be used by
>> >> > schedulers
>> >> >
>> >> >     to forcefully kill a task which is already being killed, e.g. if
>> >> > something
>> >> >
>> >> >     went wrong during a graceful kill and a forcible kill is desired.
>> >> Note
>> >> > that
>> >> >
>> >> >     it is the executor's responsibility to honor the
>> >> > 'Event.kill.kill_policy'
>> >> >
>> >> >     field and override the task's kill policy and kill policy from a
>> >> > previous
>> >> >
>> >> >     kill task request. To use this feature, schedulers and executors
>> >> must
>> >> >
>> >> >
>> >> >     support HTTP API; use the '--http_command_executor' agent flag to
>> >> > ensure
>> >> >
>> >> >     the agent launches the HTTP API based command executor.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
>> >> configured
>> >> > in
>> >> >
>> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting
>> down
>> >> an
>> >> >
>> >> >
>> >> >     executor the agent will wait in a best-effort manner for the
>> grace
>> >> > period
>> >> >
>> >> >     specified here before forcibly destroying the container. The
>> >> executor
>> >> > must
>> >> >
>> >> >     not assume that it will always be allotted the full grace
>> period, as
>> >> > the
>> >> >
>> >> >     agent may decide to allot a shorter period and failures /
>> forcible
>> >> >
>> >> >
>> >> >     terminations may occur. Together with kill policies this gives
>> >> > frameworks
>> >> >
>> >> >     flexibility around how to clean up tasks and executors.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-3094] - **Experimental** support for launching mesos
>> tasks on
>> >> >
>> >> >
>> >> >     Windows. Note that there are no isolation guarantees provided
>> yet.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
>> into
>> >> > two,
>> >> >
>> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>> >> >
>> >> >
>> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
>> >> >
>> >> >
>> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>> >> modules
>> >> > for
>> >> >
>> >> >     backwards compatibility with existing code.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete.
>> To
>> >> > support
>> >> >
>> >> >     the rename, new duplicate flags (e.g.,
>> --agent_reregister_timeout),
>> >> new
>> >> >
>> >> >
>> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>> >> added.
>> >> > All
>> >> >
>> >> >     the logging output has been updated to use the term 'agent' now.
>> >> Flags,
>> >> >
>> >> >
>> >> >     binaries and scripts with 'slave' keyword have been deprecated
>> (see
>> >> >
>> >> >
>> >> >     "Deprecations section below").
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4312] - **Experimental** support for building and running
>> >> mesos
>> >> > on
>> >> >
>> >> >     IBM PowerPC platform.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
>> >> > dynamically
>> >> >
>> >> >     via the new '/weights' endpoint on the master.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>> >> >
>> >> >
>> >> >     Mesos "unified" containerizer. This support includes running
>> >> containers
>> >> >
>> >> >
>> >> >     with and without filesystem isolation (i.e. running both
>> imageless
>> >> >
>> >> >
>> >> >     containers as well as containers using a docker image).
>> Frameworks
>> >> must
>> >> >
>> >> >
>> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>> >> >
>> >> >
>> >> >     capability (see the scarce resource problem in MESOS-5377). We
>> >> support
>> >> >
>> >> >
>> >> >     'nvidia-docker'-style docker containers by injecting a volume
>> that
>> >> >
>> >> >
>> >> >     contains the Nvidia libraries / binaries when the docker image
>> has
>> >> >
>> >> >
>> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>> >> >
>> >> >
>> >> >     containerizer will come in a future release.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >   * [MESOS-5724] - SSL certificate validation allows for additional
>> IP
>> >> > address
>> >> >
>> >> >     subject alternative name extension verification.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > The CHANGELOG for the release is available at:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>> >> >
>> >> >
>> >>
>> --------------------------------------------------------------------------------
>> >> >
>> >> >
>> >> > The candidate for Mesos 1.0.0 release is available at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>> >> >
>> >> >
>> >> > The tag to be voted on is 1.0.0-rc2:
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>> >> >
>> >> >
>> >> > The MD5 checksum of the tarball can be found at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>> >> >
>> >> >
>> >> > The signature of the tarball can be found at:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>> >> >
>> >> >
>> >> > The PGP key used to sign the release is here:
>> >> >
>> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >> >
>> >> >
>> >> > The JAR is up in Maven in a staging repository here:
>> >> >
>> >> >
>> https://repository.apache.org/content/repositories/orgapachemesos-1149
>> >> >
>> >> >
>> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
>> >> >
>> >> >
>> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>> >> > majority of at least 3 +1 PMC votes are cast.
>> >> >
>> >> >
>> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
>> >> >
>> >> > [ ] -1 Do not release this package because ...
>> >> >
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Vinod
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> >
>> > Zhitao Li
>> >
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Zhitao Li <zh...@gmail.com>]

+1 (nonbinding)

Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
on a small test cluster for both master and slave.



On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:

> None of the stable builds have SSL yet. The first SSL-enabled stable build
> will be 1.0.0. Sorry for the confusion.
>
> Kapil
>
> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> > Hi Kapil,
> >
> > Do you mean that the stable builds from
> > http://open.mesosphere.com/downloads/mesos is using the new
> configuration?
> >
> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >
> >> The binary rpm/deb packages can be found here:
> >>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
> >> .
> >>
> >> Please note that starting with the 1.0.0 release (including RCs and
> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
> >> module dependency installation. Here is the configure command line:
> >>     ./configure --enable-libevent --enable-ssl
> >> --enable-install-module-dependencies
> >>
> >> As always, the stable builds are available at:
> >>     http://open.mesosphere.com/downloads/mesos
> >>
> >> The instructions for nightly builds are available at:
> >>     http://open.mesosphere.com/downloads/mesos-nightly/
> >>
> >> Best,
> >> Kapil
> >>
> >>
> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
> wrote:
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > Please vote on releasing the following candidate as Apache Mesos
> 1.0.0.
> >> >
> >> >
> >> > 1.0.0 includes the following:
> >> >
> >> >
> >>
> --------------------------------------------------------------------------------
> >> >
> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
> >> APIs.
> >> > These
> >> >
> >> >     APIs let operators and services (monitoring, load balancers) send
> >> HTTP
> >> >
> >> >
> >> >     requests to '/api/v1' endpoint on master or agent. See
> >> >
> >> >
> >> >     `docs/operator-http-api.md` for details.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
> >> isolator
> >> >
> >> >
> >> >     has been added to isolate disk resources more efficiently. Please
> >> refer
> >> > to
> >> >
> >> >     docs/mesos-containerizer.md for more details.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin.
> We
> >> > added a
> >> >
> >> >     new isolator 'docker/volume' which allows users to use external
> >> volumes
> >> > in
> >> >
> >> >     Mesos containerizer. Currently, the isolator interacts with the
> >> Docker
> >> >
> >> >
> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
> Docker
> >> > volume
> >> >
> >> >     plugin API, most of the Docker volume plugins are supported.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
> >> >
> >> >
> >> >     `network/cni` isolator, has been introduced in the
> >> > `MesosContainerizer`. The
> >> >
> >> >     `network/cni` isolator implements the Container Network Interface
> >> (CNI)
> >> >
> >> >
> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
> >> isolator
> >> > is
> >> >
> >> >     able to allocate a network namespace to Mesos containers and
> attach
> >> the
> >> >
> >> >
> >> >     container to different types of IP networks by invoking network
> >> drivers
> >> >
> >> >
> >> >     called CNI plugins.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> >> refactored
> >> > in
> >> >
> >> >     order to decouple the ACLs definition language from the interface.
> >> >
> >> >
> >> >     It additionally includes the option of retrieving
> `ObjectApprover`.
> >> An
> >> >
> >> >
> >> >     `ObjectApprover` can be used to synchronously check authorizations
> >> for
> >> > a
> >> >
> >> >     given object and is hence useful when authorizing a large number
> of
> >> > objects
> >> >
> >> >     and/or large objects (which need to be copied using request based
> >> >
> >> >
> >> >     authorization). NOTE: This is a **breaking change** for authorizer
> >> > modules.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-5405] - The `subject` and `object` fields in
> >> > authorization::Request
> >> >
> >> >     have been changed from required to optional. If either of these
> >> fields
> >> > is
> >> >
> >> >     not set, the request should only be authorized if any
> subject/object
> >> > should
> >> >
> >> >     be allowed.
> >> >
> >> >     NOTE: This is a semantic change for authorizer modules.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> >> > endpoint
> >> >
> >> >     filtering enables operators to restrict what part of the cluster
> >> state
> >> > a
> >> >
> >> >     user is authorized to see.
> >> >
> >> >
> >> >     Consider for example the `/state` master endpoint: an operator can
> >> now
> >> >
> >> >
> >> >     authorize users to only see a subset of the running frameworks,
> >> tasks,
> >> > or
> >> >
> >> >     executors. The following endpoints support HTTP endpoint
> filtering:
> >> >
> >> >
> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
> >> >
> >> >
> >> >     and '/roles'. Additonally the following v1 API calls support
> >> filtering:
> >> >
> >> >
> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> >> > 'GET_TASKS'.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> >> > best-effort,
> >> >
> >> >     because machine failures or forcible terminations may occur.
> >> Currently,
> >> > the
> >> >
> >> >     only available kill policy is how long to wait between graceful
> and
> >> > forcible
> >> >
> >> >     task kill. In the future, more policies may be available (e.g.
> >> hitting
> >> > an
> >> >
> >> >     HTTP endpoint, running a command, etc). Note that it is the
> >> executor's
> >> >
> >> >
> >> >     responsibility to enforce kill policies. For executor-less
> >> > command-based
> >> >
> >> >     tasks, the kill is performed via sending a signal to the task
> >> process:
> >> >
> >> >
> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill.
> For
> >> > docker
> >> >
> >> >     executor-less tasks the grace period is passed to 'docker stop
> >> --time'.
> >> > This
> >> >
> >> >     feature supersedes the '--docker_stop_timeout', which is now
> >> > deprecated.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
> >> now
> >> > be
> >> >
> >> >     overridden when the scheduler kills the task. This can be used by
> >> > schedulers
> >> >
> >> >     to forcefully kill a task which is already being killed, e.g. if
> >> > something
> >> >
> >> >     went wrong during a graceful kill and a forcible kill is desired.
> >> Note
> >> > that
> >> >
> >> >     it is the executor's responsibility to honor the
> >> > 'Event.kill.kill_policy'
> >> >
> >> >     field and override the task's kill policy and kill policy from a
> >> > previous
> >> >
> >> >     kill task request. To use this feature, schedulers and executors
> >> must
> >> >
> >> >
> >> >     support HTTP API; use the '--http_command_executor' agent flag to
> >> > ensure
> >> >
> >> >     the agent launches the HTTP API based command executor.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
> >> configured
> >> > in
> >> >
> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting down
> >> an
> >> >
> >> >
> >> >     executor the agent will wait in a best-effort manner for the grace
> >> > period
> >> >
> >> >     specified here before forcibly destroying the container. The
> >> executor
> >> > must
> >> >
> >> >     not assume that it will always be allotted the full grace period,
> as
> >> > the
> >> >
> >> >     agent may decide to allot a shorter period and failures / forcible
> >> >
> >> >
> >> >     terminations may occur. Together with kill policies this gives
> >> > frameworks
> >> >
> >> >     flexibility around how to clean up tasks and executors.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks
> on
> >> >
> >> >
> >> >     Windows. Note that there are no isolation guarantees provided yet.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
> into
> >> > two,
> >> >
> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
> >> >
> >> >
> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
> >> >
> >> >
> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
> >> modules
> >> > for
> >> >
> >> >     backwards compatibility with existing code.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete.
> To
> >> > support
> >> >
> >> >     the rename, new duplicate flags (e.g.,
> --agent_reregister_timeout),
> >> new
> >> >
> >> >
> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
> >> added.
> >> > All
> >> >
> >> >     the logging output has been updated to use the term 'agent' now.
> >> Flags,
> >> >
> >> >
> >> >     binaries and scripts with 'slave' keyword have been deprecated
> (see
> >> >
> >> >
> >> >     "Deprecations section below").
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4312] - **Experimental** support for building and running
> >> mesos
> >> > on
> >> >
> >> >     IBM PowerPC platform.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
> >> > dynamically
> >> >
> >> >     via the new '/weights' endpoint on the master.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
> >> >
> >> >
> >> >     Mesos "unified" containerizer. This support includes running
> >> containers
> >> >
> >> >
> >> >     with and without filesystem isolation (i.e. running both imageless
> >> >
> >> >
> >> >     containers as well as containers using a docker image). Frameworks
> >> must
> >> >
> >> >
> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
> >> >
> >> >
> >> >     capability (see the scarce resource problem in MESOS-5377). We
> >> support
> >> >
> >> >
> >> >     'nvidia-docker'-style docker containers by injecting a volume that
> >> >
> >> >
> >> >     contains the Nvidia libraries / binaries when the docker image has
> >> >
> >> >
> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
> >> >
> >> >
> >> >     containerizer will come in a future release.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
> >> > address
> >> >
> >> >     subject alternative name extension verification.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > The CHANGELOG for the release is available at:
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >> >
> >> >
> >>
> --------------------------------------------------------------------------------
> >> >
> >> >
> >> > The candidate for Mesos 1.0.0 release is available at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >> >
> >> >
> >> > The tag to be voted on is 1.0.0-rc2:
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >> >
> >> >
> >> > The MD5 checksum of the tarball can be found at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >> >
> >> >
> >> > The signature of the tarball can be found at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >> >
> >> >
> >> > The PGP key used to sign the release is here:
> >> >
> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >> >
> >> >
> >> > The JAR is up in Maven in a staging repository here:
> >> >
> >> >
> https://repository.apache.org/content/repositories/orgapachemesos-1149
> >> >
> >> >
> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >> >
> >> >
> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> >> > majority of at least 3 +1 PMC votes are cast.
> >> >
> >> >
> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >> >
> >> > [ ] -1 Do not release this package because ...
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Vinod
> >>
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>



-- 
Cheers,

Zhitao Li

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Zhitao Li <zh...@gmail.com>]

+1 (nonbinding)

Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade
on a small test cluster for both master and slave.



On Mon, Jul 11, 2016 at 10:13 AM, Kapil Arya <ka...@mesosphere.io> wrote:

> None of the stable builds have SSL yet. The first SSL-enabled stable build
> will be 1.0.0. Sorry for the confusion.
>
> Kapil
>
> On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> > Hi Kapil,
> >
> > Do you mean that the stable builds from
> > http://open.mesosphere.com/downloads/mesos is using the new
> configuration?
> >
> > On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >
> >> The binary rpm/deb packages can be found here:
> >>
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
> >> .
> >>
> >> Please note that starting with the 1.0.0 release (including RCs and
> >> recent nightly builds), Mesos is configured with SSL and 3rdparty
> >> module dependency installation. Here is the configure command line:
> >>     ./configure --enable-libevent --enable-ssl
> >> --enable-install-module-dependencies
> >>
> >> As always, the stable builds are available at:
> >>     http://open.mesosphere.com/downloads/mesos
> >>
> >> The instructions for nightly builds are available at:
> >>     http://open.mesosphere.com/downloads/mesos-nightly/
> >>
> >> Best,
> >> Kapil
> >>
> >>
> >> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org>
> wrote:
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > Please vote on releasing the following candidate as Apache Mesos
> 1.0.0.
> >> >
> >> >
> >> > 1.0.0 includes the following:
> >> >
> >> >
> >>
> --------------------------------------------------------------------------------
> >> >
> >> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
> >> APIs.
> >> > These
> >> >
> >> >     APIs let operators and services (monitoring, load balancers) send
> >> HTTP
> >> >
> >> >
> >> >     requests to '/api/v1' endpoint on master or agent. See
> >> >
> >> >
> >> >     `docs/operator-http-api.md` for details.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
> >> isolator
> >> >
> >> >
> >> >     has been added to isolate disk resources more efficiently. Please
> >> refer
> >> > to
> >> >
> >> >     docs/mesos-containerizer.md for more details.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin.
> We
> >> > added a
> >> >
> >> >     new isolator 'docker/volume' which allows users to use external
> >> volumes
> >> > in
> >> >
> >> >     Mesos containerizer. Currently, the isolator interacts with the
> >> Docker
> >> >
> >> >
> >> >     volume plugins using a tool called 'dvdcli'. By speaking the
> Docker
> >> > volume
> >> >
> >> >     plugin API, most of the Docker volume plugins are supported.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4641] - **Experimental** A new network isolator, the
> >> >
> >> >
> >> >     `network/cni` isolator, has been introduced in the
> >> > `MesosContainerizer`. The
> >> >
> >> >     `network/cni` isolator implements the Container Network Interface
> >> (CNI)
> >> >
> >> >
> >> >     specification proposed by CoreOS.  With CNI the `network/cni`
> >> isolator
> >> > is
> >> >
> >> >     able to allocate a network namespace to Mesos containers and
> attach
> >> the
> >> >
> >> >
> >> >     container to different types of IP networks by invoking network
> >> drivers
> >> >
> >> >
> >> >     called CNI plugins.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> >> refactored
> >> > in
> >> >
> >> >     order to decouple the ACLs definition language from the interface.
> >> >
> >> >
> >> >     It additionally includes the option of retrieving
> `ObjectApprover`.
> >> An
> >> >
> >> >
> >> >     `ObjectApprover` can be used to synchronously check authorizations
> >> for
> >> > a
> >> >
> >> >     given object and is hence useful when authorizing a large number
> of
> >> > objects
> >> >
> >> >     and/or large objects (which need to be copied using request based
> >> >
> >> >
> >> >     authorization). NOTE: This is a **breaking change** for authorizer
> >> > modules.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-5405] - The `subject` and `object` fields in
> >> > authorization::Request
> >> >
> >> >     have been changed from required to optional. If either of these
> >> fields
> >> > is
> >> >
> >> >     not set, the request should only be authorized if any
> subject/object
> >> > should
> >> >
> >> >     be allowed.
> >> >
> >> >     NOTE: This is a semantic change for authorizer modules.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> >> > endpoint
> >> >
> >> >     filtering enables operators to restrict what part of the cluster
> >> state
> >> > a
> >> >
> >> >     user is authorized to see.
> >> >
> >> >
> >> >     Consider for example the `/state` master endpoint: an operator can
> >> now
> >> >
> >> >
> >> >     authorize users to only see a subset of the running frameworks,
> >> tasks,
> >> > or
> >> >
> >> >     executors. The following endpoints support HTTP endpoint
> filtering:
> >> >
> >> >
> >> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
> >> >
> >> >
> >> >     and '/roles'. Additonally the following v1 API calls support
> >> filtering:
> >> >
> >> >
> >> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> >> > 'GET_TASKS'.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> >> > best-effort,
> >> >
> >> >     because machine failures or forcible terminations may occur.
> >> Currently,
> >> > the
> >> >
> >> >     only available kill policy is how long to wait between graceful
> and
> >> > forcible
> >> >
> >> >     task kill. In the future, more policies may be available (e.g.
> >> hitting
> >> > an
> >> >
> >> >     HTTP endpoint, running a command, etc). Note that it is the
> >> executor's
> >> >
> >> >
> >> >     responsibility to enforce kill policies. For executor-less
> >> > command-based
> >> >
> >> >     tasks, the kill is performed via sending a signal to the task
> >> process:
> >> >
> >> >
> >> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill.
> For
> >> > docker
> >> >
> >> >     executor-less tasks the grace period is passed to 'docker stop
> >> --time'.
> >> > This
> >> >
> >> >     feature supersedes the '--docker_stop_timeout', which is now
> >> > deprecated.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
> >> now
> >> > be
> >> >
> >> >     overridden when the scheduler kills the task. This can be used by
> >> > schedulers
> >> >
> >> >     to forcefully kill a task which is already being killed, e.g. if
> >> > something
> >> >
> >> >     went wrong during a graceful kill and a forcible kill is desired.
> >> Note
> >> > that
> >> >
> >> >     it is the executor's responsibility to honor the
> >> > 'Event.kill.kill_policy'
> >> >
> >> >     field and override the task's kill policy and kill policy from a
> >> > previous
> >> >
> >> >     kill task request. To use this feature, schedulers and executors
> >> must
> >> >
> >> >
> >> >     support HTTP API; use the '--http_command_executor' agent flag to
> >> > ensure
> >> >
> >> >     the agent launches the HTTP API based command executor.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4949] - The executor shutdown grace period can now be
> >> configured
> >> > in
> >> >
> >> >     `ExecutorInfo`, which overrides the agent flag. When shutting down
> >> an
> >> >
> >> >
> >> >     executor the agent will wait in a best-effort manner for the grace
> >> > period
> >> >
> >> >     specified here before forcibly destroying the container. The
> >> executor
> >> > must
> >> >
> >> >     not assume that it will always be allotted the full grace period,
> as
> >> > the
> >> >
> >> >     agent may decide to allot a shorter period and failures / forcible
> >> >
> >> >
> >> >     terminations may occur. Together with kill policies this gives
> >> > frameworks
> >> >
> >> >     flexibility around how to clean up tasks and executors.
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks
> on
> >> >
> >> >
> >> >     Windows. Note that there are no isolation guarantees provided yet.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4090] - The `mesos.native` python module has been split
> into
> >> > two,
> >> >
> >> >     `mesos.executor` and `mesos.scheduler`. This change also removes
> >> >
> >> >
> >> >     un-necessary 3rd party dependencies from `mesos.executor` and
> >> >
> >> >
> >> >     `mesos.scheduler`. `mesos.native` still exists, combining both
> >> modules
> >> > for
> >> >
> >> >     backwards compatibility with existing code.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete.
> To
> >> > support
> >> >
> >> >     the rename, new duplicate flags (e.g.,
> --agent_reregister_timeout),
> >> new
> >> >
> >> >
> >> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
> >> added.
> >> > All
> >> >
> >> >     the logging output has been updated to use the term 'agent' now.
> >> Flags,
> >> >
> >> >
> >> >     binaries and scripts with 'slave' keyword have been deprecated
> (see
> >> >
> >> >
> >> >     "Deprecations section below").
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4312] - **Experimental** support for building and running
> >> mesos
> >> > on
> >> >
> >> >     IBM PowerPC platform.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4189] - Weights for resource roles can now be configured
> >> > dynamically
> >> >
> >> >     via the new '/weights' endpoint on the master.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
> >> >
> >> >
> >> >     Mesos "unified" containerizer. This support includes running
> >> containers
> >> >
> >> >
> >> >     with and without filesystem isolation (i.e. running both imageless
> >> >
> >> >
> >> >     containers as well as containers using a docker image). Frameworks
> >> must
> >> >
> >> >
> >> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
> >> >
> >> >
> >> >     capability (see the scarce resource problem in MESOS-5377). We
> >> support
> >> >
> >> >
> >> >     'nvidia-docker'-style docker containers by injecting a volume that
> >> >
> >> >
> >> >     contains the Nvidia libraries / binaries when the docker image has
> >> >
> >> >
> >> >     the 'com.nvidia.volumes.needed' label. Support for the docker
> >> >
> >> >
> >> >     containerizer will come in a future release.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
> >> > address
> >> >
> >> >     subject alternative name extension verification.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > The CHANGELOG for the release is available at:
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >> >
> >> >
> >>
> --------------------------------------------------------------------------------
> >> >
> >> >
> >> > The candidate for Mesos 1.0.0 release is available at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >> >
> >> >
> >> > The tag to be voted on is 1.0.0-rc2:
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >> >
> >> >
> >> > The MD5 checksum of the tarball can be found at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >> >
> >> >
> >> > The signature of the tarball can be found at:
> >> >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >> >
> >> >
> >> > The PGP key used to sign the release is here:
> >> >
> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >> >
> >> >
> >> > The JAR is up in Maven in a staging repository here:
> >> >
> >> >
> https://repository.apache.org/content/repositories/orgapachemesos-1149
> >> >
> >> >
> >> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >> >
> >> >
> >> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> >> > majority of at least 3 +1 PMC votes are cast.
> >> >
> >> >
> >> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >> >
> >> > [ ] -1 Do not release this package because ...
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Vinod
> >>
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>



-- 
Cheers,

Zhitao Li

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Kapil Arya <ka...@mesosphere.io>]

None of the stable builds have SSL yet. The first SSL-enabled stable build
will be 1.0.0. Sorry for the confusion.

Kapil

On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:

> Hi Kapil,
>
> Do you mean that the stable builds from
> http://open.mesosphere.com/downloads/mesos is using the new configuration?
>
> On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> The binary rpm/deb packages can be found here:
>>     http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>> .
>>
>> Please note that starting with the 1.0.0 release (including RCs and
>> recent nightly builds), Mesos is configured with SSL and 3rdparty
>> module dependency installation. Here is the configure command line:
>>     ./configure --enable-libevent --enable-ssl
>> --enable-install-module-dependencies
>>
>> As always, the stable builds are available at:
>>     http://open.mesosphere.com/downloads/mesos
>>
>> The instructions for nightly builds are available at:
>>     http://open.mesosphere.com/downloads/mesos-nightly/
>>
>> Best,
>> Kapil
>>
>>
>> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>> >
>> >
>> > 1.0.0 includes the following:
>> >
>> >
>> --------------------------------------------------------------------------------
>> >
>> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> APIs.
>> > These
>> >
>> >     APIs let operators and services (monitoring, load balancers) send
>> HTTP
>> >
>> >
>> >     requests to '/api/v1' endpoint on master or agent. See
>> >
>> >
>> >     `docs/operator-http-api.md` for details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> isolator
>> >
>> >
>> >     has been added to isolate disk resources more efficiently. Please
>> refer
>> > to
>> >
>> >     docs/mesos-containerizer.md for more details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
>> > added a
>> >
>> >     new isolator 'docker/volume' which allows users to use external
>> volumes
>> > in
>> >
>> >     Mesos containerizer. Currently, the isolator interacts with the
>> Docker
>> >
>> >
>> >     volume plugins using a tool called 'dvdcli'. By speaking the Docker
>> > volume
>> >
>> >     plugin API, most of the Docker volume plugins are supported.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>> >
>> >
>> >     `network/cni` isolator, has been introduced in the
>> > `MesosContainerizer`. The
>> >
>> >     `network/cni` isolator implements the Container Network Interface
>> (CNI)
>> >
>> >
>> >     specification proposed by CoreOS.  With CNI the `network/cni`
>> isolator
>> > is
>> >
>> >     able to allocate a network namespace to Mesos containers and attach
>> the
>> >
>> >
>> >     container to different types of IP networks by invoking network
>> drivers
>> >
>> >
>> >     called CNI plugins.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>> refactored
>> > in
>> >
>> >     order to decouple the ACLs definition language from the interface.
>> >
>> >
>> >     It additionally includes the option of retrieving `ObjectApprover`.
>> An
>> >
>> >
>> >     `ObjectApprover` can be used to synchronously check authorizations
>> for
>> > a
>> >
>> >     given object and is hence useful when authorizing a large number of
>> > objects
>> >
>> >     and/or large objects (which need to be copied using request based
>> >
>> >
>> >     authorization). NOTE: This is a **breaking change** for authorizer
>> > modules.
>> >
>> >
>> >
>> >
>> >   * [MESOS-5405] - The `subject` and `object` fields in
>> > authorization::Request
>> >
>> >     have been changed from required to optional. If either of these
>> fields
>> > is
>> >
>> >     not set, the request should only be authorized if any subject/object
>> > should
>> >
>> >     be allowed.
>> >
>> >     NOTE: This is a semantic change for authorizer modules.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>> > endpoint
>> >
>> >     filtering enables operators to restrict what part of the cluster
>> state
>> > a
>> >
>> >     user is authorized to see.
>> >
>> >
>> >     Consider for example the `/state` master endpoint: an operator can
>> now
>> >
>> >
>> >     authorize users to only see a subset of the running frameworks,
>> tasks,
>> > or
>> >
>> >     executors. The following endpoints support HTTP endpoint filtering:
>> >
>> >
>> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>> >
>> >
>> >     and '/roles'. Additonally the following v1 API calls support
>> filtering:
>> >
>> >
>> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>> > 'GET_TASKS'.
>> >
>> >
>> >
>> >
>> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>> > best-effort,
>> >
>> >     because machine failures or forcible terminations may occur.
>> Currently,
>> > the
>> >
>> >     only available kill policy is how long to wait between graceful and
>> > forcible
>> >
>> >     task kill. In the future, more policies may be available (e.g.
>> hitting
>> > an
>> >
>> >     HTTP endpoint, running a command, etc). Note that it is the
>> executor's
>> >
>> >
>> >     responsibility to enforce kill policies. For executor-less
>> > command-based
>> >
>> >     tasks, the kill is performed via sending a signal to the task
>> process:
>> >
>> >
>> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
>> > docker
>> >
>> >     executor-less tasks the grace period is passed to 'docker stop
>> --time'.
>> > This
>> >
>> >     feature supersedes the '--docker_stop_timeout', which is now
>> > deprecated.
>> >
>> >
>> >
>> >
>> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
>> now
>> > be
>> >
>> >     overridden when the scheduler kills the task. This can be used by
>> > schedulers
>> >
>> >     to forcefully kill a task which is already being killed, e.g. if
>> > something
>> >
>> >     went wrong during a graceful kill and a forcible kill is desired.
>> Note
>> > that
>> >
>> >     it is the executor's responsibility to honor the
>> > 'Event.kill.kill_policy'
>> >
>> >     field and override the task's kill policy and kill policy from a
>> > previous
>> >
>> >     kill task request. To use this feature, schedulers and executors
>> must
>> >
>> >
>> >     support HTTP API; use the '--http_command_executor' agent flag to
>> > ensure
>> >
>> >     the agent launches the HTTP API based command executor.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4949] - The executor shutdown grace period can now be
>> configured
>> > in
>> >
>> >     `ExecutorInfo`, which overrides the agent flag. When shutting down
>> an
>> >
>> >
>> >     executor the agent will wait in a best-effort manner for the grace
>> > period
>> >
>> >     specified here before forcibly destroying the container. The
>> executor
>> > must
>> >
>> >     not assume that it will always be allotted the full grace period, as
>> > the
>> >
>> >     agent may decide to allot a shorter period and failures / forcible
>> >
>> >
>> >     terminations may occur. Together with kill policies this gives
>> > frameworks
>> >
>> >     flexibility around how to clean up tasks and executors.
>> >
>> >
>> >
>> >
>> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
>> >
>> >
>> >     Windows. Note that there are no isolation guarantees provided yet.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4090] - The `mesos.native` python module has been split into
>> > two,
>> >
>> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>> >
>> >
>> >     un-necessary 3rd party dependencies from `mesos.executor` and
>> >
>> >
>> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>> modules
>> > for
>> >
>> >     backwards compatibility with existing code.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
>> > support
>> >
>> >     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
>> new
>> >
>> >
>> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>> added.
>> > All
>> >
>> >     the logging output has been updated to use the term 'agent' now.
>> Flags,
>> >
>> >
>> >     binaries and scripts with 'slave' keyword have been deprecated (see
>> >
>> >
>> >     "Deprecations section below").
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4312] - **Experimental** support for building and running
>> mesos
>> > on
>> >
>> >     IBM PowerPC platform.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4189] - Weights for resource roles can now be configured
>> > dynamically
>> >
>> >     via the new '/weights' endpoint on the master.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>> >
>> >
>> >     Mesos "unified" containerizer. This support includes running
>> containers
>> >
>> >
>> >     with and without filesystem isolation (i.e. running both imageless
>> >
>> >
>> >     containers as well as containers using a docker image). Frameworks
>> must
>> >
>> >
>> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>> >
>> >
>> >     capability (see the scarce resource problem in MESOS-5377). We
>> support
>> >
>> >
>> >     'nvidia-docker'-style docker containers by injecting a volume that
>> >
>> >
>> >     contains the Nvidia libraries / binaries when the docker image has
>> >
>> >
>> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>> >
>> >
>> >     containerizer will come in a future release.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
>> > address
>> >
>> >     subject alternative name extension verification.
>> >
>> >
>> >
>> >
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>> >
>> >
>> --------------------------------------------------------------------------------
>> >
>> >
>> > The candidate for Mesos 1.0.0 release is available at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>> >
>> >
>> > The tag to be voted on is 1.0.0-rc2:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>> >
>> >
>> > The MD5 checksum of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>> >
>> >
>> > The signature of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>> >
>> >
>> > The PGP key used to sign the release is here:
>> >
>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >
>> >
>> > The JAR is up in Maven in a staging repository here:
>> >
>> > https://repository.apache.org/content/repositories/orgapachemesos-1149
>> >
>> >
>> > Please vote on releasing this package as Apache Mesos 1.0.0!
>> >
>> >
>> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>> > majority of at least 3 +1 PMC votes are cast.
>> >
>> >
>> > [ ] +1 Release this package as Apache Mesos 1.0.0
>> >
>> > [ ] -1 Do not release this package because ...
>> >
>> >
>> > Thanks,
>> >
>> > Vinod
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Kapil Arya <ka...@mesosphere.io>]

None of the stable builds have SSL yet. The first SSL-enabled stable build
will be 1.0.0. Sorry for the confusion.

Kapil

On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zh...@gmail.com> wrote:

> Hi Kapil,
>
> Do you mean that the stable builds from
> http://open.mesosphere.com/downloads/mesos is using the new configuration?
>
> On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> The binary rpm/deb packages can be found here:
>>     http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>> .
>>
>> Please note that starting with the 1.0.0 release (including RCs and
>> recent nightly builds), Mesos is configured with SSL and 3rdparty
>> module dependency installation. Here is the configure command line:
>>     ./configure --enable-libevent --enable-ssl
>> --enable-install-module-dependencies
>>
>> As always, the stable builds are available at:
>>     http://open.mesosphere.com/downloads/mesos
>>
>> The instructions for nightly builds are available at:
>>     http://open.mesosphere.com/downloads/mesos-nightly/
>>
>> Best,
>> Kapil
>>
>>
>> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>> >
>> >
>> > 1.0.0 includes the following:
>> >
>> >
>> --------------------------------------------------------------------------------
>> >
>> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> APIs.
>> > These
>> >
>> >     APIs let operators and services (monitoring, load balancers) send
>> HTTP
>> >
>> >
>> >     requests to '/api/v1' endpoint on master or agent. See
>> >
>> >
>> >     `docs/operator-http-api.md` for details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> isolator
>> >
>> >
>> >     has been added to isolate disk resources more efficiently. Please
>> refer
>> > to
>> >
>> >     docs/mesos-containerizer.md for more details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
>> > added a
>> >
>> >     new isolator 'docker/volume' which allows users to use external
>> volumes
>> > in
>> >
>> >     Mesos containerizer. Currently, the isolator interacts with the
>> Docker
>> >
>> >
>> >     volume plugins using a tool called 'dvdcli'. By speaking the Docker
>> > volume
>> >
>> >     plugin API, most of the Docker volume plugins are supported.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>> >
>> >
>> >     `network/cni` isolator, has been introduced in the
>> > `MesosContainerizer`. The
>> >
>> >     `network/cni` isolator implements the Container Network Interface
>> (CNI)
>> >
>> >
>> >     specification proposed by CoreOS.  With CNI the `network/cni`
>> isolator
>> > is
>> >
>> >     able to allocate a network namespace to Mesos containers and attach
>> the
>> >
>> >
>> >     container to different types of IP networks by invoking network
>> drivers
>> >
>> >
>> >     called CNI plugins.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>> refactored
>> > in
>> >
>> >     order to decouple the ACLs definition language from the interface.
>> >
>> >
>> >     It additionally includes the option of retrieving `ObjectApprover`.
>> An
>> >
>> >
>> >     `ObjectApprover` can be used to synchronously check authorizations
>> for
>> > a
>> >
>> >     given object and is hence useful when authorizing a large number of
>> > objects
>> >
>> >     and/or large objects (which need to be copied using request based
>> >
>> >
>> >     authorization). NOTE: This is a **breaking change** for authorizer
>> > modules.
>> >
>> >
>> >
>> >
>> >   * [MESOS-5405] - The `subject` and `object` fields in
>> > authorization::Request
>> >
>> >     have been changed from required to optional. If either of these
>> fields
>> > is
>> >
>> >     not set, the request should only be authorized if any subject/object
>> > should
>> >
>> >     be allowed.
>> >
>> >     NOTE: This is a semantic change for authorizer modules.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
>> > endpoint
>> >
>> >     filtering enables operators to restrict what part of the cluster
>> state
>> > a
>> >
>> >     user is authorized to see.
>> >
>> >
>> >     Consider for example the `/state` master endpoint: an operator can
>> now
>> >
>> >
>> >     authorize users to only see a subset of the running frameworks,
>> tasks,
>> > or
>> >
>> >     executors. The following endpoints support HTTP endpoint filtering:
>> >
>> >
>> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>> >
>> >
>> >     and '/roles'. Additonally the following v1 API calls support
>> filtering:
>> >
>> >
>> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
>> > 'GET_TASKS'.
>> >
>> >
>> >
>> >
>> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
>> > best-effort,
>> >
>> >     because machine failures or forcible terminations may occur.
>> Currently,
>> > the
>> >
>> >     only available kill policy is how long to wait between graceful and
>> > forcible
>> >
>> >     task kill. In the future, more policies may be available (e.g.
>> hitting
>> > an
>> >
>> >     HTTP endpoint, running a command, etc). Note that it is the
>> executor's
>> >
>> >
>> >     responsibility to enforce kill policies. For executor-less
>> > command-based
>> >
>> >     tasks, the kill is performed via sending a signal to the task
>> process:
>> >
>> >
>> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
>> > docker
>> >
>> >     executor-less tasks the grace period is passed to 'docker stop
>> --time'.
>> > This
>> >
>> >     feature supersedes the '--docker_stop_timeout', which is now
>> > deprecated.
>> >
>> >
>> >
>> >
>> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can
>> now
>> > be
>> >
>> >     overridden when the scheduler kills the task. This can be used by
>> > schedulers
>> >
>> >     to forcefully kill a task which is already being killed, e.g. if
>> > something
>> >
>> >     went wrong during a graceful kill and a forcible kill is desired.
>> Note
>> > that
>> >
>> >     it is the executor's responsibility to honor the
>> > 'Event.kill.kill_policy'
>> >
>> >     field and override the task's kill policy and kill policy from a
>> > previous
>> >
>> >     kill task request. To use this feature, schedulers and executors
>> must
>> >
>> >
>> >     support HTTP API; use the '--http_command_executor' agent flag to
>> > ensure
>> >
>> >     the agent launches the HTTP API based command executor.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4949] - The executor shutdown grace period can now be
>> configured
>> > in
>> >
>> >     `ExecutorInfo`, which overrides the agent flag. When shutting down
>> an
>> >
>> >
>> >     executor the agent will wait in a best-effort manner for the grace
>> > period
>> >
>> >     specified here before forcibly destroying the container. The
>> executor
>> > must
>> >
>> >     not assume that it will always be allotted the full grace period, as
>> > the
>> >
>> >     agent may decide to allot a shorter period and failures / forcible
>> >
>> >
>> >     terminations may occur. Together with kill policies this gives
>> > frameworks
>> >
>> >     flexibility around how to clean up tasks and executors.
>> >
>> >
>> >
>> >
>> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
>> >
>> >
>> >     Windows. Note that there are no isolation guarantees provided yet.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4090] - The `mesos.native` python module has been split into
>> > two,
>> >
>> >     `mesos.executor` and `mesos.scheduler`. This change also removes
>> >
>> >
>> >     un-necessary 3rd party dependencies from `mesos.executor` and
>> >
>> >
>> >     `mesos.scheduler`. `mesos.native` still exists, combining both
>> modules
>> > for
>> >
>> >     backwards compatibility with existing code.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
>> > support
>> >
>> >     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
>> new
>> >
>> >
>> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been
>> added.
>> > All
>> >
>> >     the logging output has been updated to use the term 'agent' now.
>> Flags,
>> >
>> >
>> >     binaries and scripts with 'slave' keyword have been deprecated (see
>> >
>> >
>> >     "Deprecations section below").
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4312] - **Experimental** support for building and running
>> mesos
>> > on
>> >
>> >     IBM PowerPC platform.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4189] - Weights for resource roles can now be configured
>> > dynamically
>> >
>> >     via the new '/weights' endpoint on the master.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>> >
>> >
>> >     Mesos "unified" containerizer. This support includes running
>> containers
>> >
>> >
>> >     with and without filesystem isolation (i.e. running both imageless
>> >
>> >
>> >     containers as well as containers using a docker image). Frameworks
>> must
>> >
>> >
>> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>> >
>> >
>> >     capability (see the scarce resource problem in MESOS-5377). We
>> support
>> >
>> >
>> >     'nvidia-docker'-style docker containers by injecting a volume that
>> >
>> >
>> >     contains the Nvidia libraries / binaries when the docker image has
>> >
>> >
>> >     the 'com.nvidia.volumes.needed' label. Support for the docker
>> >
>> >
>> >     containerizer will come in a future release.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
>> > address
>> >
>> >     subject alternative name extension verification.
>> >
>> >
>> >
>> >
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>> >
>> >
>> --------------------------------------------------------------------------------
>> >
>> >
>> > The candidate for Mesos 1.0.0 release is available at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>> >
>> >
>> > The tag to be voted on is 1.0.0-rc2:
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>> >
>> >
>> > The MD5 checksum of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>> >
>> >
>> > The signature of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>> >
>> >
>> > The PGP key used to sign the release is here:
>> >
>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >
>> >
>> > The JAR is up in Maven in a staging repository here:
>> >
>> > https://repository.apache.org/content/repositories/orgapachemesos-1149
>> >
>> >
>> > Please vote on releasing this package as Apache Mesos 1.0.0!
>> >
>> >
>> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
>> > majority of at least 3 +1 PMC votes are cast.
>> >
>> >
>> > [ ] +1 Release this package as Apache Mesos 1.0.0
>> >
>> > [ ] -1 Do not release this package because ...
>> >
>> >
>> > Thanks,
>> >
>> > Vinod
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Zhitao Li <zh...@gmail.com>]

Hi Kapil,

Do you mean that the stable builds from
http://open.mesosphere.com/downloads/mesos is using the new configuration?

On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> wrote:

> The binary rpm/deb packages can be found here:
>     http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2.
>
> Please note that starting with the 1.0.0 release (including RCs and
> recent nightly builds), Mesos is configured with SSL and 3rdparty
> module dependency installation. Here is the configure command line:
>     ./configure --enable-libevent --enable-ssl
> --enable-install-module-dependencies
>
> As always, the stable builds are available at:
>     http://open.mesosphere.com/downloads/mesos
>
> The instructions for nightly builds are available at:
>     http://open.mesosphere.com/downloads/mesos-nightly/
>
> Best,
> Kapil
>
>
> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
> >
> > Hi all,
> >
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
> >
> >
> > 1.0.0 includes the following:
> >
> >
> --------------------------------------------------------------------------------
> >
> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
> >
> >
> >
> >
> >
> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> > These
> >
> >     APIs let operators and services (monitoring, load balancers) send
> HTTP
> >
> >
> >     requests to '/api/v1' endpoint on master or agent. See
> >
> >
> >     `docs/operator-http-api.md` for details.
> >
> >
> >
> >
> >
> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
> >
> >
> >     has been added to isolate disk resources more efficiently. Please
> refer
> > to
> >
> >     docs/mesos-containerizer.md for more details.
> >
> >
> >
> >
> >
> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> > added a
> >
> >     new isolator 'docker/volume' which allows users to use external
> volumes
> > in
> >
> >     Mesos containerizer. Currently, the isolator interacts with the
> Docker
> >
> >
> >     volume plugins using a tool called 'dvdcli'. By speaking the Docker
> > volume
> >
> >     plugin API, most of the Docker volume plugins are supported.
> >
> >
> >
> >
> >
> >   * [MESOS-4641] - **Experimental** A new network isolator, the
> >
> >
> >     `network/cni` isolator, has been introduced in the
> > `MesosContainerizer`. The
> >
> >     `network/cni` isolator implements the Container Network Interface
> (CNI)
> >
> >
> >     specification proposed by CoreOS.  With CNI the `network/cni`
> isolator
> > is
> >
> >     able to allocate a network namespace to Mesos containers and attach
> the
> >
> >
> >     container to different types of IP networks by invoking network
> drivers
> >
> >
> >     called CNI plugins.
> >
> >
> >
> >
> >
> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> refactored
> > in
> >
> >     order to decouple the ACLs definition language from the interface.
> >
> >
> >     It additionally includes the option of retrieving `ObjectApprover`.
> An
> >
> >
> >     `ObjectApprover` can be used to synchronously check authorizations
> for
> > a
> >
> >     given object and is hence useful when authorizing a large number of
> > objects
> >
> >     and/or large objects (which need to be copied using request based
> >
> >
> >     authorization). NOTE: This is a **breaking change** for authorizer
> > modules.
> >
> >
> >
> >
> >   * [MESOS-5405] - The `subject` and `object` fields in
> > authorization::Request
> >
> >     have been changed from required to optional. If either of these
> fields
> > is
> >
> >     not set, the request should only be authorized if any subject/object
> > should
> >
> >     be allowed.
> >
> >     NOTE: This is a semantic change for authorizer modules.
> >
> >
> >
> >
> >
> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> > endpoint
> >
> >     filtering enables operators to restrict what part of the cluster
> state
> > a
> >
> >     user is authorized to see.
> >
> >
> >     Consider for example the `/state` master endpoint: an operator can
> now
> >
> >
> >     authorize users to only see a subset of the running frameworks,
> tasks,
> > or
> >
> >     executors. The following endpoints support HTTP endpoint filtering:
> >
> >
> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
> >
> >
> >     and '/roles'. Additonally the following v1 API calls support
> filtering:
> >
> >
> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> > 'GET_TASKS'.
> >
> >
> >
> >
> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> > best-effort,
> >
> >     because machine failures or forcible terminations may occur.
> Currently,
> > the
> >
> >     only available kill policy is how long to wait between graceful and
> > forcible
> >
> >     task kill. In the future, more policies may be available (e.g.
> hitting
> > an
> >
> >     HTTP endpoint, running a command, etc). Note that it is the
> executor's
> >
> >
> >     responsibility to enforce kill policies. For executor-less
> > command-based
> >
> >     tasks, the kill is performed via sending a signal to the task
> process:
> >
> >
> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> > docker
> >
> >     executor-less tasks the grace period is passed to 'docker stop
> --time'.
> > This
> >
> >     feature supersedes the '--docker_stop_timeout', which is now
> > deprecated.
> >
> >
> >
> >
> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> > be
> >
> >     overridden when the scheduler kills the task. This can be used by
> > schedulers
> >
> >     to forcefully kill a task which is already being killed, e.g. if
> > something
> >
> >     went wrong during a graceful kill and a forcible kill is desired.
> Note
> > that
> >
> >     it is the executor's responsibility to honor the
> > 'Event.kill.kill_policy'
> >
> >     field and override the task's kill policy and kill policy from a
> > previous
> >
> >     kill task request. To use this feature, schedulers and executors must
> >
> >
> >     support HTTP API; use the '--http_command_executor' agent flag to
> > ensure
> >
> >     the agent launches the HTTP API based command executor.
> >
> >
> >
> >
> >
> >   * [MESOS-4949] - The executor shutdown grace period can now be
> configured
> > in
> >
> >     `ExecutorInfo`, which overrides the agent flag. When shutting down an
> >
> >
> >     executor the agent will wait in a best-effort manner for the grace
> > period
> >
> >     specified here before forcibly destroying the container. The executor
> > must
> >
> >     not assume that it will always be allotted the full grace period, as
> > the
> >
> >     agent may decide to allot a shorter period and failures / forcible
> >
> >
> >     terminations may occur. Together with kill policies this gives
> > frameworks
> >
> >     flexibility around how to clean up tasks and executors.
> >
> >
> >
> >
> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
> >
> >
> >     Windows. Note that there are no isolation guarantees provided yet.
> >
> >
> >
> >
> >
> >   * [MESOS-4090] - The `mesos.native` python module has been split into
> > two,
> >
> >     `mesos.executor` and `mesos.scheduler`. This change also removes
> >
> >
> >     un-necessary 3rd party dependencies from `mesos.executor` and
> >
> >
> >     `mesos.scheduler`. `mesos.native` still exists, combining both
> modules
> > for
> >
> >     backwards compatibility with existing code.
> >
> >
> >
> >
> >
> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
> > support
> >
> >     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
> new
> >
> >
> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been added.
> > All
> >
> >     the logging output has been updated to use the term 'agent' now.
> Flags,
> >
> >
> >     binaries and scripts with 'slave' keyword have been deprecated (see
> >
> >
> >     "Deprecations section below").
> >
> >
> >
> >
> >
> >   * [MESOS-4312] - **Experimental** support for building and running
> mesos
> > on
> >
> >     IBM PowerPC platform.
> >
> >
> >
> >
> >
> >   * [MESOS-4189] - Weights for resource roles can now be configured
> > dynamically
> >
> >     via the new '/weights' endpoint on the master.
> >
> >
> >
> >
> >
> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
> >
> >
> >     Mesos "unified" containerizer. This support includes running
> containers
> >
> >
> >     with and without filesystem isolation (i.e. running both imageless
> >
> >
> >     containers as well as containers using a docker image). Frameworks
> must
> >
> >
> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
> >
> >
> >     capability (see the scarce resource problem in MESOS-5377). We
> support
> >
> >
> >     'nvidia-docker'-style docker containers by injecting a volume that
> >
> >
> >     contains the Nvidia libraries / binaries when the docker image has
> >
> >
> >     the 'com.nvidia.volumes.needed' label. Support for the docker
> >
> >
> >     containerizer will come in a future release.
> >
> >
> >
> >
> >
> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
> > address
> >
> >     subject alternative name extension verification.
> >
> >
> >
> >
> >
> > The CHANGELOG for the release is available at:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >
> >
> --------------------------------------------------------------------------------
> >
> >
> > The candidate for Mesos 1.0.0 release is available at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >
> >
> > The tag to be voted on is 1.0.0-rc2:
> >
> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >
> >
> > The MD5 checksum of the tarball can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >
> >
> > The signature of the tarball can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >
> >
> > The PGP key used to sign the release is here:
> >
> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >
> >
> > The JAR is up in Maven in a staging repository here:
> >
> > https://repository.apache.org/content/repositories/orgapachemesos-1149
> >
> >
> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >
> >
> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> >
> >
> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >
> > [ ] -1 Do not release this package because ...
> >
> >
> > Thanks,
> >
> > Vinod
>



-- 
Cheers,

Zhitao Li

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Zhitao Li <zh...@gmail.com>]

Hi Kapil,

Do you mean that the stable builds from
http://open.mesosphere.com/downloads/mesos is using the new configuration?

On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> wrote:

> The binary rpm/deb packages can be found here:
>     http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2.
>
> Please note that starting with the 1.0.0 release (including RCs and
> recent nightly builds), Mesos is configured with SSL and 3rdparty
> module dependency installation. Here is the configure command line:
>     ./configure --enable-libevent --enable-ssl
> --enable-install-module-dependencies
>
> As always, the stable builds are available at:
>     http://open.mesosphere.com/downloads/mesos
>
> The instructions for nightly builds are available at:
>     http://open.mesosphere.com/downloads/mesos-nightly/
>
> Best,
> Kapil
>
>
> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
> >
> > Hi all,
> >
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
> >
> >
> > 1.0.0 includes the following:
> >
> >
> --------------------------------------------------------------------------------
> >
> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
> >
> >
> >
> >
> >
> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> > These
> >
> >     APIs let operators and services (monitoring, load balancers) send
> HTTP
> >
> >
> >     requests to '/api/v1' endpoint on master or agent. See
> >
> >
> >     `docs/operator-http-api.md` for details.
> >
> >
> >
> >
> >
> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
> >
> >
> >     has been added to isolate disk resources more efficiently. Please
> refer
> > to
> >
> >     docs/mesos-containerizer.md for more details.
> >
> >
> >
> >
> >
> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> > added a
> >
> >     new isolator 'docker/volume' which allows users to use external
> volumes
> > in
> >
> >     Mesos containerizer. Currently, the isolator interacts with the
> Docker
> >
> >
> >     volume plugins using a tool called 'dvdcli'. By speaking the Docker
> > volume
> >
> >     plugin API, most of the Docker volume plugins are supported.
> >
> >
> >
> >
> >
> >   * [MESOS-4641] - **Experimental** A new network isolator, the
> >
> >
> >     `network/cni` isolator, has been introduced in the
> > `MesosContainerizer`. The
> >
> >     `network/cni` isolator implements the Container Network Interface
> (CNI)
> >
> >
> >     specification proposed by CoreOS.  With CNI the `network/cni`
> isolator
> > is
> >
> >     able to allocate a network namespace to Mesos containers and attach
> the
> >
> >
> >     container to different types of IP networks by invoking network
> drivers
> >
> >
> >     called CNI plugins.
> >
> >
> >
> >
> >
> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> refactored
> > in
> >
> >     order to decouple the ACLs definition language from the interface.
> >
> >
> >     It additionally includes the option of retrieving `ObjectApprover`.
> An
> >
> >
> >     `ObjectApprover` can be used to synchronously check authorizations
> for
> > a
> >
> >     given object and is hence useful when authorizing a large number of
> > objects
> >
> >     and/or large objects (which need to be copied using request based
> >
> >
> >     authorization). NOTE: This is a **breaking change** for authorizer
> > modules.
> >
> >
> >
> >
> >   * [MESOS-5405] - The `subject` and `object` fields in
> > authorization::Request
> >
> >     have been changed from required to optional. If either of these
> fields
> > is
> >
> >     not set, the request should only be authorized if any subject/object
> > should
> >
> >     be allowed.
> >
> >     NOTE: This is a semantic change for authorizer modules.
> >
> >
> >
> >
> >
> >   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> > endpoint
> >
> >     filtering enables operators to restrict what part of the cluster
> state
> > a
> >
> >     user is authorized to see.
> >
> >
> >     Consider for example the `/state` master endpoint: an operator can
> now
> >
> >
> >     authorize users to only see a subset of the running frameworks,
> tasks,
> > or
> >
> >     executors. The following endpoints support HTTP endpoint filtering:
> >
> >
> >     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
> >
> >
> >     and '/roles'. Additonally the following v1 API calls support
> filtering:
> >
> >
> >     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> > 'GET_TASKS'.
> >
> >
> >
> >
> >   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> > best-effort,
> >
> >     because machine failures or forcible terminations may occur.
> Currently,
> > the
> >
> >     only available kill policy is how long to wait between graceful and
> > forcible
> >
> >     task kill. In the future, more policies may be available (e.g.
> hitting
> > an
> >
> >     HTTP endpoint, running a command, etc). Note that it is the
> executor's
> >
> >
> >     responsibility to enforce kill policies. For executor-less
> > command-based
> >
> >     tasks, the kill is performed via sending a signal to the task
> process:
> >
> >
> >     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> > docker
> >
> >     executor-less tasks the grace period is passed to 'docker stop
> --time'.
> > This
> >
> >     feature supersedes the '--docker_stop_timeout', which is now
> > deprecated.
> >
> >
> >
> >
> >   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> > be
> >
> >     overridden when the scheduler kills the task. This can be used by
> > schedulers
> >
> >     to forcefully kill a task which is already being killed, e.g. if
> > something
> >
> >     went wrong during a graceful kill and a forcible kill is desired.
> Note
> > that
> >
> >     it is the executor's responsibility to honor the
> > 'Event.kill.kill_policy'
> >
> >     field and override the task's kill policy and kill policy from a
> > previous
> >
> >     kill task request. To use this feature, schedulers and executors must
> >
> >
> >     support HTTP API; use the '--http_command_executor' agent flag to
> > ensure
> >
> >     the agent launches the HTTP API based command executor.
> >
> >
> >
> >
> >
> >   * [MESOS-4949] - The executor shutdown grace period can now be
> configured
> > in
> >
> >     `ExecutorInfo`, which overrides the agent flag. When shutting down an
> >
> >
> >     executor the agent will wait in a best-effort manner for the grace
> > period
> >
> >     specified here before forcibly destroying the container. The executor
> > must
> >
> >     not assume that it will always be allotted the full grace period, as
> > the
> >
> >     agent may decide to allot a shorter period and failures / forcible
> >
> >
> >     terminations may occur. Together with kill policies this gives
> > frameworks
> >
> >     flexibility around how to clean up tasks and executors.
> >
> >
> >
> >
> >   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
> >
> >
> >     Windows. Note that there are no isolation guarantees provided yet.
> >
> >
> >
> >
> >
> >   * [MESOS-4090] - The `mesos.native` python module has been split into
> > two,
> >
> >     `mesos.executor` and `mesos.scheduler`. This change also removes
> >
> >
> >     un-necessary 3rd party dependencies from `mesos.executor` and
> >
> >
> >     `mesos.scheduler`. `mesos.native` still exists, combining both
> modules
> > for
> >
> >     backwards compatibility with existing code.
> >
> >
> >
> >
> >
> >   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
> > support
> >
> >     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
> new
> >
> >
> >     binaries (e.g., mesos-agent) and WebUI sandbox links have been added.
> > All
> >
> >     the logging output has been updated to use the term 'agent' now.
> Flags,
> >
> >
> >     binaries and scripts with 'slave' keyword have been deprecated (see
> >
> >
> >     "Deprecations section below").
> >
> >
> >
> >
> >
> >   * [MESOS-4312] - **Experimental** support for building and running
> mesos
> > on
> >
> >     IBM PowerPC platform.
> >
> >
> >
> >
> >
> >   * [MESOS-4189] - Weights for resource roles can now be configured
> > dynamically
> >
> >     via the new '/weights' endpoint on the master.
> >
> >
> >
> >
> >
> >   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
> >
> >
> >     Mesos "unified" containerizer. This support includes running
> containers
> >
> >
> >     with and without filesystem isolation (i.e. running both imageless
> >
> >
> >     containers as well as containers using a docker image). Frameworks
> must
> >
> >
> >     opt-in to receiving GPU resources via the GPU_RESOURCES framework
> >
> >
> >     capability (see the scarce resource problem in MESOS-5377). We
> support
> >
> >
> >     'nvidia-docker'-style docker containers by injecting a volume that
> >
> >
> >     contains the Nvidia libraries / binaries when the docker image has
> >
> >
> >     the 'com.nvidia.volumes.needed' label. Support for the docker
> >
> >
> >     containerizer will come in a future release.
> >
> >
> >
> >
> >
> >   * [MESOS-5724] - SSL certificate validation allows for additional IP
> > address
> >
> >     subject alternative name extension verification.
> >
> >
> >
> >
> >
> > The CHANGELOG for the release is available at:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
> >
> >
> --------------------------------------------------------------------------------
> >
> >
> > The candidate for Mesos 1.0.0 release is available at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
> >
> >
> > The tag to be voted on is 1.0.0-rc2:
> >
> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
> >
> >
> > The MD5 checksum of the tarball can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
> >
> >
> > The signature of the tarball can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
> >
> >
> > The PGP key used to sign the release is here:
> >
> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >
> >
> > The JAR is up in Maven in a staging repository here:
> >
> > https://repository.apache.org/content/repositories/orgapachemesos-1149
> >
> >
> > Please vote on releasing this package as Apache Mesos 1.0.0!
> >
> >
> > The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> >
> >
> > [ ] +1 Release this package as Apache Mesos 1.0.0
> >
> > [ ] -1 Do not release this package because ...
> >
> >
> > Thanks,
> >
> > Vinod
>



-- 
Cheers,

Zhitao Li

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Kapil Arya <ka...@mesosphere.io>]

The binary rpm/deb packages can be found here:
    http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2.

Please note that starting with the 1.0.0 release (including RCs and
recent nightly builds), Mesos is configured with SSL and 3rdparty
module dependency installation. Here is the configure command line:
    ./configure --enable-libevent --enable-ssl
--enable-install-module-dependencies

As always, the stable builds are available at:
    http://open.mesosphere.com/downloads/mesos

The instructions for nightly builds are available at:
    http://open.mesosphere.com/downloads/mesos-nightly/

Best,
Kapil

On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>
>
> 1.0.0 includes the following:
>
>
--------------------------------------------------------------------------------
>
>   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>
>
>
>
>
>   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> These
>
>     APIs let operators and services (monitoring, load balancers) send HTTP
>
>
>     requests to '/api/v1' endpoint on master or agent. See
>
>
>     `docs/operator-http-api.md` for details.
>
>
>
>
>
>   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
>
>
>     has been added to isolate disk resources more efficiently. Please
refer
> to
>
>     docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> added a
>
>     new isolator 'docker/volume' which allows users to use external
volumes
> in
>
>     Mesos containerizer. Currently, the isolator interacts with the Docker
>
>
>     volume plugins using a tool called 'dvdcli'. By speaking the Docker
> volume
>
>     plugin API, most of the Docker volume plugins are supported.
>
>
>
>
>
>   * [MESOS-4641] - **Experimental** A new network isolator, the
>
>
>     `network/cni` isolator, has been introduced in the
> `MesosContainerizer`. The
>
>     `network/cni` isolator implements the Container Network Interface
(CNI)
>
>
>     specification proposed by CoreOS.  With CNI the `network/cni` isolator
> is
>
>     able to allocate a network namespace to Mesos containers and attach
the
>
>
>     container to different types of IP networks by invoking network
drivers
>
>
>     called CNI plugins.
>
>
>
>
>
>   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
refactored
> in
>
>     order to decouple the ACLs definition language from the interface.
>
>
>     It additionally includes the option of retrieving `ObjectApprover`. An
>
>
>     `ObjectApprover` can be used to synchronously check authorizations for
> a
>
>     given object and is hence useful when authorizing a large number of
> objects
>
>     and/or large objects (which need to be copied using request based
>
>
>     authorization). NOTE: This is a **breaking change** for authorizer
> modules.
>
>
>
>
>   * [MESOS-5405] - The `subject` and `object` fields in
> authorization::Request
>
>     have been changed from required to optional. If either of these fields
> is
>
>     not set, the request should only be authorized if any subject/object
> should
>
>     be allowed.
>
>     NOTE: This is a semantic change for authorizer modules.
>
>
>
>
>
>   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> endpoint
>
>     filtering enables operators to restrict what part of the cluster state
> a
>
>     user is authorized to see.
>
>
>     Consider for example the `/state` master endpoint: an operator can now
>
>
>     authorize users to only see a subset of the running frameworks, tasks,
> or
>
>     executors. The following endpoints support HTTP endpoint filtering:
>
>
>     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>
>
>     and '/roles'. Additonally the following v1 API calls support
filtering:
>
>
>     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> 'GET_TASKS'.
>
>
>
>
>   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> best-effort,
>
>     because machine failures or forcible terminations may occur.
Currently,
> the
>
>     only available kill policy is how long to wait between graceful and
> forcible
>
>     task kill. In the future, more policies may be available (e.g. hitting
> an
>
>     HTTP endpoint, running a command, etc). Note that it is the executor's
>
>
>     responsibility to enforce kill policies. For executor-less
> command-based
>
>     tasks, the kill is performed via sending a signal to the task process:
>
>
>     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> docker
>
>     executor-less tasks the grace period is passed to 'docker stop
--time'.
> This
>
>     feature supersedes the '--docker_stop_timeout', which is now
> deprecated.
>
>
>
>
>   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> be
>
>     overridden when the scheduler kills the task. This can be used by
> schedulers
>
>     to forcefully kill a task which is already being killed, e.g. if
> something
>
>     went wrong during a graceful kill and a forcible kill is desired. Note
> that
>
>     it is the executor's responsibility to honor the
> 'Event.kill.kill_policy'
>
>     field and override the task's kill policy and kill policy from a
> previous
>
>     kill task request. To use this feature, schedulers and executors must
>
>
>     support HTTP API; use the '--http_command_executor' agent flag to
> ensure
>
>     the agent launches the HTTP API based command executor.
>
>
>
>
>
>   * [MESOS-4949] - The executor shutdown grace period can now be
configured
> in
>
>     `ExecutorInfo`, which overrides the agent flag. When shutting down an
>
>
>     executor the agent will wait in a best-effort manner for the grace
> period
>
>     specified here before forcibly destroying the container. The executor
> must
>
>     not assume that it will always be allotted the full grace period, as
> the
>
>     agent may decide to allot a shorter period and failures / forcible
>
>
>     terminations may occur. Together with kill policies this gives
> frameworks
>
>     flexibility around how to clean up tasks and executors.
>
>
>
>
>   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
>
>
>     Windows. Note that there are no isolation guarantees provided yet.
>
>
>
>
>
>   * [MESOS-4090] - The `mesos.native` python module has been split into
> two,
>
>     `mesos.executor` and `mesos.scheduler`. This change also removes
>
>
>     un-necessary 3rd party dependencies from `mesos.executor` and
>
>
>     `mesos.scheduler`. `mesos.native` still exists, combining both modules
> for
>
>     backwards compatibility with existing code.
>
>
>
>
>
>   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
> support
>
>     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
new
>
>
>     binaries (e.g., mesos-agent) and WebUI sandbox links have been added.
> All
>
>     the logging output has been updated to use the term 'agent' now.
Flags,
>
>
>     binaries and scripts with 'slave' keyword have been deprecated (see
>
>
>     "Deprecations section below").
>
>
>
>
>
>   * [MESOS-4312] - **Experimental** support for building and running mesos
> on
>
>     IBM PowerPC platform.
>
>
>
>
>
>   * [MESOS-4189] - Weights for resource roles can now be configured
> dynamically
>
>     via the new '/weights' endpoint on the master.
>
>
>
>
>
>   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>
>
>     Mesos "unified" containerizer. This support includes running
containers
>
>
>     with and without filesystem isolation (i.e. running both imageless
>
>
>     containers as well as containers using a docker image). Frameworks
must
>
>
>     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>
>
>     capability (see the scarce resource problem in MESOS-5377). We support
>
>
>     'nvidia-docker'-style docker containers by injecting a volume that
>
>
>     contains the Nvidia libraries / binaries when the docker image has
>
>
>     the 'com.nvidia.volumes.needed' label. Support for the docker
>
>
>     containerizer will come in a future release.
>
>
>
>
>
>   * [MESOS-5724] - SSL certificate validation allows for additional IP
> address
>
>     subject alternative name extension verification.
>
>
>
>
>
> The CHANGELOG for the release is available at:
>
>
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>
>
--------------------------------------------------------------------------------
>
>
> The candidate for Mesos 1.0.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>
>
> The tag to be voted on is 1.0.0-rc2:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>
>
> The MD5 checksum of the tarball can be found at:
>
>
https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>
>
> The PGP key used to sign the release is here:
>
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
>
> The JAR is up in Maven in a staging repository here:
>
> https://repository.apache.org/content/repositories/orgapachemesos-1149
>
>
> Please vote on releasing this package as Apache Mesos 1.0.0!
>
>
> The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Mesos 1.0.0
>
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
>
> Vinod

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

[Kapil Arya <ka...@mesosphere.io>]

The binary rpm/deb packages can be found here:
    http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2.

Please note that starting with the 1.0.0 release (including RCs and
recent nightly builds), Mesos is configured with SSL and 3rdparty
module dependency installation. Here is the configure command line:
    ./configure --enable-libevent --enable-ssl
--enable-install-module-dependencies

As always, the stable builds are available at:
    http://open.mesosphere.com/downloads/mesos

The instructions for nightly builds are available at:
    http://open.mesosphere.com/downloads/mesos-nightly/

Best,
Kapil

On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vi...@apache.org> wrote:
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>
>
> 1.0.0 includes the following:
>
>
--------------------------------------------------------------------------------
>
>   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>
>
>
>
>
>   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> These
>
>     APIs let operators and services (monitoring, load balancers) send HTTP
>
>
>     requests to '/api/v1' endpoint on master or agent. See
>
>
>     `docs/operator-http-api.md` for details.
>
>
>
>
>
>   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
>
>
>     has been added to isolate disk resources more efficiently. Please
refer
> to
>
>     docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> added a
>
>     new isolator 'docker/volume' which allows users to use external
volumes
> in
>
>     Mesos containerizer. Currently, the isolator interacts with the Docker
>
>
>     volume plugins using a tool called 'dvdcli'. By speaking the Docker
> volume
>
>     plugin API, most of the Docker volume plugins are supported.
>
>
>
>
>
>   * [MESOS-4641] - **Experimental** A new network isolator, the
>
>
>     `network/cni` isolator, has been introduced in the
> `MesosContainerizer`. The
>
>     `network/cni` isolator implements the Container Network Interface
(CNI)
>
>
>     specification proposed by CoreOS.  With CNI the `network/cni` isolator
> is
>
>     able to allocate a network namespace to Mesos containers and attach
the
>
>
>     container to different types of IP networks by invoking network
drivers
>
>
>     called CNI plugins.
>
>
>
>
>
>   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
refactored
> in
>
>     order to decouple the ACLs definition language from the interface.
>
>
>     It additionally includes the option of retrieving `ObjectApprover`. An
>
>
>     `ObjectApprover` can be used to synchronously check authorizations for
> a
>
>     given object and is hence useful when authorizing a large number of
> objects
>
>     and/or large objects (which need to be copied using request based
>
>
>     authorization). NOTE: This is a **breaking change** for authorizer
> modules.
>
>
>
>
>   * [MESOS-5405] - The `subject` and `object` fields in
> authorization::Request
>
>     have been changed from required to optional. If either of these fields
> is
>
>     not set, the request should only be authorized if any subject/object
> should
>
>     be allowed.
>
>     NOTE: This is a semantic change for authorizer modules.
>
>
>
>
>
>   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> endpoint
>
>     filtering enables operators to restrict what part of the cluster state
> a
>
>     user is authorized to see.
>
>
>     Consider for example the `/state` master endpoint: an operator can now
>
>
>     authorize users to only see a subset of the running frameworks, tasks,
> or
>
>     executors. The following endpoints support HTTP endpoint filtering:
>
>
>     '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>
>
>     and '/roles'. Additonally the following v1 API calls support
filtering:
>
>
>     'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> 'GET_TASKS'.
>
>
>
>
>   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> best-effort,
>
>     because machine failures or forcible terminations may occur.
Currently,
> the
>
>     only available kill policy is how long to wait between graceful and
> forcible
>
>     task kill. In the future, more policies may be available (e.g. hitting
> an
>
>     HTTP endpoint, running a command, etc). Note that it is the executor's
>
>
>     responsibility to enforce kill policies. For executor-less
> command-based
>
>     tasks, the kill is performed via sending a signal to the task process:
>
>
>     SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> docker
>
>     executor-less tasks the grace period is passed to 'docker stop
--time'.
> This
>
>     feature supersedes the '--docker_stop_timeout', which is now
> deprecated.
>
>
>
>
>   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> be
>
>     overridden when the scheduler kills the task. This can be used by
> schedulers
>
>     to forcefully kill a task which is already being killed, e.g. if
> something
>
>     went wrong during a graceful kill and a forcible kill is desired. Note
> that
>
>     it is the executor's responsibility to honor the
> 'Event.kill.kill_policy'
>
>     field and override the task's kill policy and kill policy from a
> previous
>
>     kill task request. To use this feature, schedulers and executors must
>
>
>     support HTTP API; use the '--http_command_executor' agent flag to
> ensure
>
>     the agent launches the HTTP API based command executor.
>
>
>
>
>
>   * [MESOS-4949] - The executor shutdown grace period can now be
configured
> in
>
>     `ExecutorInfo`, which overrides the agent flag. When shutting down an
>
>
>     executor the agent will wait in a best-effort manner for the grace
> period
>
>     specified here before forcibly destroying the container. The executor
> must
>
>     not assume that it will always be allotted the full grace period, as
> the
>
>     agent may decide to allot a shorter period and failures / forcible
>
>
>     terminations may occur. Together with kill policies this gives
> frameworks
>
>     flexibility around how to clean up tasks and executors.
>
>
>
>
>   * [MESOS-3094] - **Experimental** support for launching mesos tasks on
>
>
>     Windows. Note that there are no isolation guarantees provided yet.
>
>
>
>
>
>   * [MESOS-4090] - The `mesos.native` python module has been split into
> two,
>
>     `mesos.executor` and `mesos.scheduler`. This change also removes
>
>
>     un-necessary 3rd party dependencies from `mesos.executor` and
>
>
>     `mesos.scheduler`. `mesos.native` still exists, combining both modules
> for
>
>     backwards compatibility with existing code.
>
>
>
>
>
>   * [MESOS-1478] - Phase I of the Slave to Agent rename is complete. To
> support
>
>     the rename, new duplicate flags (e.g., --agent_reregister_timeout),
new
>
>
>     binaries (e.g., mesos-agent) and WebUI sandbox links have been added.
> All
>
>     the logging output has been updated to use the term 'agent' now.
Flags,
>
>
>     binaries and scripts with 'slave' keyword have been deprecated (see
>
>
>     "Deprecations section below").
>
>
>
>
>
>   * [MESOS-4312] - **Experimental** support for building and running mesos
> on
>
>     IBM PowerPC platform.
>
>
>
>
>
>   * [MESOS-4189] - Weights for resource roles can now be configured
> dynamically
>
>     via the new '/weights' endpoint on the master.
>
>
>
>
>
>   * [MESOS-4424] - Support for using Nvidia GPUs as a resource in the
>
>
>     Mesos "unified" containerizer. This support includes running
containers
>
>
>     with and without filesystem isolation (i.e. running both imageless
>
>
>     containers as well as containers using a docker image). Frameworks
must
>
>
>     opt-in to receiving GPU resources via the GPU_RESOURCES framework
>
>
>     capability (see the scarce resource problem in MESOS-5377). We support
>
>
>     'nvidia-docker'-style docker containers by injecting a volume that
>
>
>     contains the Nvidia libraries / binaries when the docker image has
>
>
>     the 'com.nvidia.volumes.needed' label. Support for the docker
>
>
>     containerizer will come in a future release.
>
>
>
>
>
>   * [MESOS-5724] - SSL certificate validation allows for additional IP
> address
>
>     subject alternative name extension verification.
>
>
>
>
>
> The CHANGELOG for the release is available at:
>
>
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.0-rc2
>
>
--------------------------------------------------------------------------------
>
>
> The candidate for Mesos 1.0.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz
>
>
> The tag to be voted on is 1.0.0-rc2:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc2
>
>
> The MD5 checksum of the tarball can be found at:
>
>
https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc2/mesos-1.0.0.tar.gz.asc
>
>
> The PGP key used to sign the release is here:
>
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
>
> The JAR is up in Maven in a staging repository here:
>
> https://repository.apache.org/content/repositories/orgapachemesos-1149
>
>
> Please vote on releasing this package as Apache Mesos 1.0.0!
>
>
> The vote is open until Tue Jul 12 15:00:00 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Mesos 1.0.0
>
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
>
> Vinod