mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yan Xu <xuj...@apple.com>
Subject Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)
Date Tue, 26 Jul 2016 23:08:29 GMT
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 <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
View raw message