Yan, are you going to shepherd the fix for this one? If yes, when do you think it can be done?
- Jie On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu <[email protected]> wrote: > -1 > > We tested it in our testing environment but webUI redirect didn't work. We > filed: https://issues.apache.org/jira/browse/MESOS-5911 > > Given that webUI is the portal for Mesos clusters I feel that we should at > least have a basic fix (more context in the JIRA) before release 1.0. > Thoughts? > > On Jul 26, 2016, at 2:52 PM, Kapil Arya <[email protected]> wrote: > > +1 (binding) > > OpenSUSE Tumbleweed: > ./configure --disable-java --disable-python && make check > > On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> >> 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 >> > > >
