Thanks for catching this bug. We need to fix convert.cpp to make scheduler/executor upgrades to 1.0 easier. @Robert/@Yan: Can one of you file a JIRA issue for this? A patch would be even better :)
I'm cancelling the vote for 1.0-RC1 now. We'll cut RC2 after we fix this and any other issues that cropped up so far. On Tue, Jun 7, 2016 at 6:13 PM, Yan Xu <[email protected]> wrote: > What do you think about this Vinod? > > I think we can remove this major version checking altogether. > Backwards-incompatible changes would warrant a major version bump but not > vise versa. Plus it's more standard to express and check dependency > versions outside of the code but through package metadata. > > Yan > > On Mon, Jun 6, 2016 at 7:32 PM, Robert Lacroix <[email protected]> wrote: > >> Hi Vinod, >> >> In convert.cpp >> <https://github.com/apache/mesos/blob/master/src/java/jni/convert.cpp#L153> >> we >> compare the major versions of the native library and the jar. This makes >> upgrading frameworks unnecessarily hard because you would have to deploy >> Mesos and frameworks in lockstep. >> >> Non-binding -1 😜, as this check isn’t strictly useful - especially given >> this is probably the last major upgrade where libmesos is even relevant. >> >>  Robert >> >> On Jun 1, 2016, at 12:38 AM, Vinod Kone <[email protected]> wrote: >> >> Hi all, >> >> Please vote on releasing the following candidate as Apache Mesos 1.0.0. >> >> >> NOTE: The voting period for this release is 3 weeks. Also, we are willing >> to make API changes before the final release. So please test it >> thoroughly. >> >> >> 1.0.0 includes the following features: >> >> >> -------------------------------------------------------------------------------- >> >> * 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. These APIs look >> similar >> >> to the v1 Scheduler and Executor APIs. >> >> >> >> >> >> * [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-4931] - 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 >> >> executors. >> >> >> >> >> >> * [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 >> >> >> 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] - **Experimental** limited support for using Nvidia GPU as >> a >> >> resource. This initial support works when there is no container >> filesystem >> >> isolation in use. Improvements to the support to come in future >> releases. >> >> >> >> >> Deprecations: >> >> >> * [MESOS-2281] - Deprecated the plain text format for credentials in >> favor of >> >> the JSON format. >> >> >> >> >> >> * [MESOS-4910] - Deprecate the --docker_stop_timeout agent flag. >> >> >> >> >> >> * [MESOS-5001] - The 'allocator/event_queue_dispatches' metric is now >> >> >> deprecated in favor 'of allocator/mesos/event_queue_dispatches'. >> >> >> >> >> >> * [MESOS-5029] - Deprecated the ExecutorInfo.source field in favor of >> >> >> ExecutorInfo.labels. >> >> >> >> >> >> * [MESOS-3781] - Deprecated flags with keyword 'slave' in favor of >> 'agent'. >> >> >> >> >> * [MESOS-3779] - Deprecated sandbox links with 'slave' keyword in the >> WebUI. >> >> >> >> >> * [MESOS-3784] - Deprecated `slave` subcommand for mesos-cli. >> >> >> >> >> >> * [MESOS-5155] - Deprecated `SET_QUOTA_WITH_ROLE` and >> >> >> `DESTROY_QUOTA_WITH_PRINCIPAL` authorization actions together with the >> >> >> corresponding ACLs in favor of a unified `UPDATE_QUOTA_WITH_ROLE`. This >> >> >> change is applicable to both local authorizer as well as any custom >> >> >> authorizer module. >> >> >> >> >> >> Additional API Changes: >> >> >> * [MESOS-4580] - Returning `202` (Accepted) for /reserve and related >> endpoints. >> >> >> >> >> * [MESOS-4735] - Added 'output_file' field to CommandInfo.URI in >> Scheduler API >> >> and v1 Scheduler HTTP API. >> >> >> >> >> >> * [MESOS-5014] - Changes Call and Event Type enums in scheduler.proto >> >> from required to optional for the purpose of backwards compatibility. >> >> >> >> >> >> * [MESOS-5015] - Changes Call and Event Type enums in executor.proto >> >> >> from required to optional for the purpose of backwards compatibility. >> >> >> >> >> >> * [MESOS-5029] - Added 'labels' to ExecutorInfo. >> >> >> >> >> >> * [MESOS-5030] - Added non-terminal task metadata to the container >> resource >> >> usage information. >> >> >> >> >> >> * [MESOS-5408] - Deleted the /observe HTTP endpoint. >> >> >> >> >> >> 3rd Party Upgrades: >> >> >> * [MESOS-4805] - Upgraded vendored ry-http-parser-1c3624a to >> nodejs/http-parser 2.6.1. >> >> * [MESOS-4678] - Upgraded vendored protobuf 2.5.0 to 2.6.1. >> >> >> * [MESOS-4803] - Upgraded vendored libev 4.15 to 4.22. >> >> >> * [MESOS-4612] - Upgraded vendored ZooKeeper 3.4.5 to 3.4.8. >> >> >> >> >> >> Binary API Changes: >> >> >> * [MESOS-5055] - Slave/Agent Rename Phase I - Update strings in the log >> message >> >> and standard output. >> >> >> * [MESOS-3782] - Slave/Agent Rename Phase I - Duplicate/Rename binaries. >> >> >> * [MESOS-5057] - Slave/Agent Rename Phase I - Update strings in error >> messages and >> >> other strings. >> >> >> * [MESOS-5230] - Slave/Agent Rename Phase I: Rename >> '/include/mesos/slave' folder >> >> >> 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-rc1 >> >> >> -------------------------------------------------------------------------------- >> >> >> The candidate for Mesos 1.0.0 release is available at: >> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc1/mesos-1.0.0.tar.gz >> >> >> The tag to be voted on is 1.0.0-rc1: >> >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.0-rc1 >> >> >> The MD5 checksum of the tarball can be found at: >> >> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.0-rc1/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-rc1/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-1142 >> >> >> Please vote on releasing this package as Apache Mesos 1.0.0! >> >> >> The vote is open until *Wed Jun 22 12:00 PM PST 2016* and passes if a >> majority of at least 3 +1 PMC votes are cast. >> >> >> [ ] +1 Release this package as Apache Mesos 1.0.0 >> >> [ ] -1 Do not release this package because ... >> >> >> Thanks, >> >> >> >
