I don't mind if it's shepherd by folks with more front-end expertise. Actually my original suggested solution on https://issues.apache.org/jira/browse/MESOS-5911 <https://issues.apache.org/jira/browse/MESOS-5911> seemed incorrect. Let's discuss the actual fix on the ticket, I feel that a short term fix shouldn't be more than a few lines to unblock the release.
> On Jul 26, 2016, at 3:26 PM, Jie Yu <[email protected]> wrote: > > 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 >>> >> >> >>
