You can find the 1.0.0 rpm/deb packages at:
http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0
And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0
mesosphere/mesos-master:1.0.0
mesosphere/mesos-slave:1.0.0
Kapil
On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <[email protected]>
wrote:
> Small nit but can you s/experimnental/experimental/ under the "Storage"
> header in the release post please?
>
> Great work otherwise everyone!
>
>
> On Wednesday, July 27, 2016, Vinod Kone <[email protected]> wrote:
>
>> Hi all,
>>
>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>
>>
>> +1 (Binding)
>>
>> ------------------------------
>>
>> Kapil Arya
>>
>> Jie Yu
>>
>> Benjamin Mahler
>>
>>
>> +1 (Non-binding)
>>
>> ------------------------------
>>
>> Haosdent
>>
>> Greg Mann
>>
>> Zhitao Li
>>
>>
>> +0
>>
>> -----
>>
>> Yan Xu
>>
>>
>> There were no -1 votes.
>>
>>
>> *NOTE: There were a couple known issues [MESOS-5911
>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>
>>
>> Please find the release at:
>>
>> https://dist.apache.org/repos/dist/release/mesos/1.0.0
>>
>>
>> It is recommended to use a mirror to download the release:
>>
>> http://www.apache.org/dyn/closer.cgi
>>
>>
>> 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
>>
>>
>> The mesos-1.0.0.jar has been released to:
>>
>> https://repository.apache.org
>>
>>
>> The website (http://mesos.apache.org) will be updated shortly to reflect
>> this release.
>>
>>
>> Thanks,
>>
>> On Fri, Jul 22, 2016 at 10:40 PM, 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,
>>>
>>
>>
>
> --
> Text by Jeff, typos by iPhone
>
