+1 (binding)

OpenSUSE Tumbleweed:
    ./configure --disable-java --disable-python && make check

On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zhitaoli...@gmail.com> wrote:

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

Reply via email to