+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 <[email protected]> wrote:
>
>> +1
>>
>> Tested on Fedora release 23 (Twenty Three)
>>
>> - make check
>> - 1.0.0-rc2
>>
>> 2016-07-15 23:01 GMT+08:00 haosdent <[email protected]>:
>>
>>> +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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>> 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
>>
>
>
