I am OK with withdrawing -1 but I feel it's more prudent to go with 1b) or 2c) or the reason Jie mentioned. If we go with 1a) let's make sure we call out the known issue.
> On Jul 26, 2016, at 7:09 PM, Adam Bordelon <[email protected]> wrote: > > I don't like the idea of 2) bypassing the 72 hour voting period, so I'd > suggest either we: > 1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it, > then cut 1.0.1 soon after with this and other fixes. > 1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than > an official release. After 72hrs we can hopefully call rc5 the official 1.0 > (or maybe more blockers come up). We could have more blogs/press then about > the official 1.0 release. > 1c) push the press releases and announcements out a few more days. Not sure > if this is possible at this point? > I'd prefer 1c) if possible, or a/b otherwise. > > On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman < > [email protected]> wrote: > >> I agree with Vinod that we should go with option 1. I think redirect is a >> valuable feature but it's not imperative for the operation of the cluster. >> >> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone <[email protected]> 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 <[email protected]> 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 <[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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>
