+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
