mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kapil Arya <ka...@mesosphere.io>
Subject Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Date Wed, 27 Jul 2016 02:07:25 GMT
+1 sounds good to me. However, if we end up going with (2), I'd commit to
test the new RC and provide a +1 tonight.

On Tue, Jul 26, 2016 at 10:02 PM, Jie Yu <yujie.jay@gmail.com> wrote:

> 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 <vinodkone@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 <xujyan@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.jay@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 <xujyan@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 <kapil@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.cs@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 <bmahler@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 <greg@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 <haosdent@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 <kapil@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 <vinodkone@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
>>
>>
>>
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message