I prefer 2 if possible. Since this is a UI fix which should be easy to validate. I am worried about people trying 1.0.0 because of the blog posts without noticing 1.0.1. If 2 does not work, I am OK with 1.
> On Jul 26, 2016, at 5:39 PM, Vinod Kone <vinodk...@apache.org> wrote: > > We've the ASF press wire and other community blog posts lined up to be posted > tomorrow, so it will be really hard to tell all those folks to postpone it > this late. I've a couple options that I want to propose > > 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this bug. > > 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in > tonight without doing the typical 72 hour voting period. > > > I'm personally leaning towards 1) given the timing and the nature of the bug. > What do others think? PMC? > >> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu <xuj...@apple.com> wrote: >> 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 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 <yujie....@gmail.com> 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 <xuj...@apple.com> 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 <ka...@mesosphere.io> wrote: >>>> >>>> +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 >
