Repository: mesos Updated Branches: refs/heads/master ec6c89b36 -> 2241fe0c6
Removed non-ASCII characters from docs. Project: http://git-wip-us.apache.org/repos/asf/mesos/repo Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/2241fe0c Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/2241fe0c Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/2241fe0c Branch: refs/heads/master Commit: 2241fe0c660dc653d6560cf6d53e1d00877fc5c5 Parents: ec6c89b Author: Alexander Rukletsov <[email protected]> Authored: Tue Mar 28 23:25:24 2017 +0200 Committer: Alexander Rukletsov <[email protected]> Committed: Tue Mar 28 23:27:15 2017 +0200 ---------------------------------------------------------------------- docs/committers.md | 2 +- docs/configuration.md | 2 +- docs/containerizer-internals.md | 6 ++--- docs/executor-http-api.md | 2 +- docs/markdown-style-guide.md | 2 +- docs/nested-container-and-task-group.md | 6 ++--- docs/newbie-guide.md | 2 +- docs/operator-http-api.md | 38 ++++++++++++++-------------- docs/quota.md | 12 ++++----- docs/replicated-log-internals.md | 20 +++++++-------- docs/upgrades.md | 4 +-- docs/versioning.md | 10 ++++---- docs/working-groups.md | 2 +- 13 files changed, 54 insertions(+), 54 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/committers.md ---------------------------------------------------------------------- diff --git a/docs/committers.md b/docs/committers.md index 1968c61..5eae1be 100644 --- a/docs/committers.md +++ b/docs/committers.md @@ -303,7 +303,7 @@ responsible for the following: * Ensuring that any hacks, known limitations, or future considerations are accompanied with TODOs as appropriate. -Weâre here to build great software together! Maintainers are a means to ensure that +We're here to build great software together! Maintainers are a means to ensure that we can continue to build great software while scaling the amount of contributors and committers in the project. The responsibilities listed above are expected from all committers in the project in the work that they do, no matter which component they http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/configuration.md ---------------------------------------------------------------------- diff --git a/docs/configuration.md b/docs/configuration.md index b8ea941..452478e 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -1627,7 +1627,7 @@ string `gpu/nvidia`. <td> Directory path of the CNI plugin binaries. The <code>network/cni</code> isolator will find CNI plugins under this directory so that it can execute -the plugins to add/delete container from the CNI networks. It is the operatorâs +the plugins to add/delete container from the CNI networks. It is the operator's responsibility to install the CNI plugin binaries in the specified directory. </td> </tr> http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/containerizer-internals.md ---------------------------------------------------------------------- diff --git a/docs/containerizer-internals.md b/docs/containerizer-internals.md index f11f8f6..a2eb9c0 100644 --- a/docs/containerizer-internals.md +++ b/docs/containerizer-internals.md @@ -106,12 +106,12 @@ Launcher is responsible for forking/destroying containers. ###### Linux launcher -* Creates a âfreezerâ cgroup for the container. -* Creates posix âpipeâ to enable communication between host (parent +* Creates a "freezer" cgroup for the container. +* Creates posix "pipe" to enable communication between host (parent process) and container process. * Spawn child process (container process) using `clone` system call. * Moves the new container process to the freezer hierarchy. -* Signals the child process to continue (execâing) by writing a +* Signals the child process to continue (exec'ing) by writing a character to the write end of the pipe in the parent process. ###### Posix launcher (TBD) http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/executor-http-api.md ---------------------------------------------------------------------- diff --git a/docs/executor-http-api.md b/docs/executor-http-api.md index d666d3c..c49c234 100644 --- a/docs/executor-http-api.md +++ b/docs/executor-http-api.md @@ -411,7 +411,7 @@ Upon detecting a disconnection from the agent, the retry behavior depends on whe Upon agent startup, an agent performs [recovery](agent-recovery.md). This allows the agent to recover status updates and reconnect with old executors. Currently, the agent supports the following recovery mechanisms specified via the `--recover` flag: -* **reconnect** (default): This mode allows the agent to reconnect with any of itâs old live executors provided the framework has enabled checkpointing. The recovery of the agent is only marked complete once all the disconnected executors have connected and hung executors have been destroyed. Hence, it is mandatory that every executor retries at least once within the interval (`MESOS_SUBSCRIPTION_BACKOFF_MAX`) to ensure it is not shutdown by the agent due to being hung/unresponsive. +* **reconnect** (default): This mode allows the agent to reconnect with any of it's old live executors provided the framework has enabled checkpointing. The recovery of the agent is only marked complete once all the disconnected executors have connected and hung executors have been destroyed. Hence, it is mandatory that every executor retries at least once within the interval (`MESOS_SUBSCRIPTION_BACKOFF_MAX`) to ensure it is not shutdown by the agent due to being hung/unresponsive. * **cleanup**: This mode kills any old live executors and then exits the agent. This is usually done by operators when making a non-compatible agent/executor upgrade. Upon receiving a `SUBSCRIBE` request from the executor of a framework with checkpointing enabled, the agent would send it a `SHUTDOWN` event as soon as it reconnects. For hung executors, the agent would wait for a duration of `--executor_shutdown_grace_period` (configurable at agent startup) and then forcefully kill the container where the executor is running in. <a name="backoff-strategies"></a> http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/markdown-style-guide.md ---------------------------------------------------------------------- diff --git a/docs/markdown-style-guide.md b/docs/markdown-style-guide.md index 77b96cb..ac40387 100644 --- a/docs/markdown-style-guide.md +++ b/docs/markdown-style-guide.md @@ -41,7 +41,7 @@ Effectively, only "minor" words of four letters or fewer, namely, conjunctions (words like __and__, __or__, __nor__, and __but__), articles (the words __a__, __an__, and __the__), and prepositions (words like __as__, __at__, __by__, __for__, __from__, __in__, __of__, __on__, __per__, __to__, __with__), are -lowercased in any heading, as long as they arenât the first word. +lowercased in any heading, as long as they aren't the first word. ## Code Examples http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/nested-container-and-task-group.md ---------------------------------------------------------------------- diff --git a/docs/nested-container-and-task-group.md b/docs/nested-container-and-task-group.md index f61d59e..7f89c26 100644 --- a/docs/nested-container-and-task-group.md +++ b/docs/nested-container-and-task-group.md @@ -29,7 +29,7 @@ pod: container's failure would cause all other containers being cleaned up. -In order to have first class support for running âpodsâ, two new +In order to have first class support for running "pods", two new primitives are introduced in Mesos: `Task Group` and `Nested Container`. @@ -124,7 +124,7 @@ To allow containers to share a network namespace: To allow containers to share an ephemeral volume: Specify the `volume/sandbox_path` isolator. * Set `TaskGroupInfo.tasks.container.volumes.source.type` as `SANDBOX_PATH`. -* Set `TaskGroupInfo.tasks.container.volumes.source.sandbox_path.type` as `PARENT` and the path relative to the parent containerâs sandbox. +* Set `TaskGroupInfo.tasks.container.volumes.source.sandbox_path.type` as `PARENT` and the path relative to the parent container's sandbox. ## Executor API @@ -292,7 +292,7 @@ executor. # Future Work * Authentication and authorization on the new Agent API. -* Command health checks inside of the containerâs mount namespace. +* Command health checks inside of the container's mount namespace. * Resource isolation for nested containers. * Resource statistics reporting for nested containers. * Multiple task groups. http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/newbie-guide.md ---------------------------------------------------------------------- diff --git a/docs/newbie-guide.md b/docs/newbie-guide.md index f558e5e..e9f2aaa 100644 --- a/docs/newbie-guide.md +++ b/docs/newbie-guide.md @@ -46,7 +46,7 @@ The following information will help provide additional guidance to execute the s ## Apache JIRA Account Pre-Requisite -Detailed steps are provided in the Mesos documentation to obtain a JIRA account. Once you have obtained a JIRA account, ensure the additional step to request addition to the list of âcontributorsâ is completed. +Detailed steps are provided in the Mesos documentation to obtain a JIRA account. Once you have obtained a JIRA account, ensure the additional step to request addition to the list of "contributors" is completed. ## Tooling Pre-Requisites http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/operator-http-api.md ---------------------------------------------------------------------- diff --git a/docs/operator-http-api.md b/docs/operator-http-api.md index 2f98841..8a2a0ae 100644 --- a/docs/operator-http-api.md +++ b/docs/operator-http-api.md @@ -40,7 +40,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_HEALTHâ + "type": "GET_HEALTH" } @@ -73,7 +73,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_FLAGSâ + "type": "GET_FLAGS" } @@ -255,7 +255,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_VERSIONâ + "type": "GET_VERSION" } @@ -266,9 +266,9 @@ HTTP/1.1 200 OK Content-Type: application/json { - âtypeâ: GET_VERSION, - âget_versionâ: { - âversion_infoâ: { + "type": "GET_VERSION", + "get_version": { + "version_info": { "version": "1.0.0", "build_date": "2016-06-24 23:18:37", "build_time": 1466810317, @@ -1358,7 +1358,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_FRAMEWORKSâ + "type": "GET_FRAMEWORKS" } @@ -1369,7 +1369,7 @@ HTTP/1.1 200 OK Content-Type: application/json { - âtypeâ: âGET_FRAMEWORKSâ, + "type": "GET_FRAMEWORKS", "get_frameworks": { "frameworks": [ { @@ -1414,7 +1414,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_EXECUTORSâ + "type": "GET_EXECUTORS" } @@ -1425,7 +1425,7 @@ HTTP/1.1 200 OK Content-Type: application/json { - âtypeâ: âGET_EXECUTORSâ, + "type": "GET_EXECUTORS", "get_executors": { "executors": [ { @@ -1670,7 +1670,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_WEIGHTSâ + "type": "GET_WEIGHTS" } @@ -1681,7 +1681,7 @@ HTTP/1.1 200 OK Content-Type: application/json { - âtypeâ: âGET_WEIGHTSâ, + "type": "GET_WEIGHTS", "get_weights": { "weight_infos": [ { @@ -2457,7 +2457,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: "GET_FLAGS" + "type": "GET_FLAGS" } @@ -2768,7 +2768,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_STATEâ + "type": "GET_STATE" } @@ -2948,7 +2948,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: âGET_CONTAINERSâ + "type": "GET_CONTAINERS" } @@ -3009,7 +3009,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: "GET_FRAMEWORKS" + "type": "GET_FRAMEWORKS" } @@ -3057,7 +3057,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: "GET_EXECUTORS" + "type": "GET_EXECUTORS" } @@ -3129,7 +3129,7 @@ Content-Type: application/json Accept: application/json { - âtypeâ: "GET_TASKS" + "type": "GET_TASKS" } @@ -3140,7 +3140,7 @@ HTTP/1.1 200 OK Content-Type: application/json { - âtypeâ: âGET_TASKSâ, + "type": "GET_TASKS", "get_tasks": { "launched_tasks": [ { http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/quota.md ---------------------------------------------------------------------- diff --git a/docs/quota.md b/docs/quota.md index 36b4853..931542b 100644 --- a/docs/quota.md +++ b/docs/quota.md @@ -39,10 +39,10 @@ resources at a particular agent, the role has a minimum guarantee of 4 CPUs, not ## Terminology -For the purpose of this document, an âOperatorâ is a person, tool, or script +For the purpose of this document, an "Operator" is a person, tool, or script that manages the Mesos cluster. -In computer science, a âquotaâ usually refers to one of the following: +In computer science, a "quota" usually refers to one of the following: * A minimal guarantee. * A maximal limit. @@ -64,8 +64,8 @@ There are two frameworks in a cluster, each running in a separate role with equal weights: framework fA in role rA and framework fB in role rB. There is a single resource available in the cluster: 100 CPUs. fA consumes 10 CPUs and is idle (declines resource offers), while fB is greedy and accepts all offers it gets, -hogging the remaining 90 CPUs. Without quota, though fAâs fair share is 50 CPUs -it will not be able to make use of additional the 40 CPUs until some of fBâs +hogging the remaining 90 CPUs. Without quota, though fA's fair share is 50 CPUs +it will not be able to make use of additional the 40 CPUs until some of fB's tasks terminate. @@ -74,7 +74,7 @@ tasks terminate. A greedy framework fB in role rB is currently the only framework in the cluster and it uses all available resources---100 CPUs. If a new framework fA in role rA joins the cluster, it will not receive its fair share of the cluster resources -(50 CPUs) until some of fBâs tasks terminate. +(50 CPUs) until some of fB's tasks terminate. To deal with Scenario 2, quota by itself is not a sufficient solution as it would be set after fB has started using all resources. Instead Scenario 2 @@ -354,7 +354,7 @@ suspension---ends when either: requested resources (e.g., 10 CPUs on a single node). * The quota set request does not allow to specify constraints (e.g., 2*5 cpus on disjoint nodes for an HA like setup). -* Quota is not allowed for the default role â*â (see +* Quota is not allowed for the default role '*' (see [MESOS-3938](https://issues.apache.org/jira/browse/MESOS-3938)). * Currently it is not possible to update previously configured quotas. See [quota set request](#setRequest) for details. http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/replicated-log-internals.md ---------------------------------------------------------------------- diff --git a/docs/replicated-log-internals.md b/docs/replicated-log-internals.md index b0295cd..66497cc 100644 --- a/docs/replicated-log-internals.md +++ b/docs/replicated-log-internals.md @@ -32,23 +32,23 @@ Similarly, the replicated log can be used to build [replicated state machines](h  -The replicated log uses the [Paxos consensus algorithm](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) to ensure that all replicas agree on every log entryâs value. It is similar to whatâs described in [these slides](https://ramcloud.stanford.edu/~ongaro/userstudy/paxos.pdf). Readers who are familiar with Paxos can skip this section. +The replicated log uses the [Paxos consensus algorithm](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) to ensure that all replicas agree on every log entry's value. It is similar to what's described in [these slides](https://ramcloud.stanford.edu/~ongaro/userstudy/paxos.pdf). Readers who are familiar with Paxos can skip this section. The above figure is an implementation overview. When a user wants to append data to the log, the system creates a log writer. The log writer internally creates a coordinator. The coordinator contacts all replicas and executes the Paxos algorithm to make sure all replicas agree about the appended data. The coordinator is sometimes referred to as the [_proposer_](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29). -Each replica keeps an array of log entries. The array index is the log position. Each log entry is composed of three components: the value written by the user, the associated Paxos state and a _learned_ bit where true means this log entryâs value has been agreed. Therefore, a replica in our implementation is both an [_acceptor_](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) and a [_learner_](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29). +Each replica keeps an array of log entries. The array index is the log position. Each log entry is composed of three components: the value written by the user, the associated Paxos state and a _learned_ bit where true means this log entry's value has been agreed. Therefore, a replica in our implementation is both an [_acceptor_](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29) and a [_learner_](https://en.wikipedia.org/wiki/Paxos_%28computer_science%29). ### Reaching consensus for a single log entry -A Paxos round can help all replicas reach consensus on a single log entryâs value. It has two phases: a promise phase and a write phase. Note that we are using slightly different terminology from the [original Paxos paper](https://research.microsoft.com/en-us/um/people/lamport/pubs/paxes-simple.pdf). In our implementation, the _prepare_ and _accept_ phases in the original paper are referred to as the _promise_ and _write_ phases, respectively. Consequently, a prepare request (response) is referred to as a promise request (response), and an accept request (response) is referred to as a write request (response). +A Paxos round can help all replicas reach consensus on a single log entry's value. It has two phases: a promise phase and a write phase. Note that we are using slightly different terminology from the [original Paxos paper](https://research.microsoft.com/en-us/um/people/lamport/pubs/paxes-simple.pdf). In our implementation, the _prepare_ and _accept_ phases in the original paper are referred to as the _promise_ and _write_ phases, respectively. Consequently, a prepare request (response) is referred to as a promise request (response), and an accept request (response) is referred to as a write request (response). To append value _X_ to the log at position _p_, the coordinator first broadcasts a promise request to all replicas with proposal number _n_, asking replicas to promise that they will not respond to any request (promise/write request) with a proposal number lower than _n_. We assume that _n_ is higher than any other previously used proposal number, and will explain how we do this later. -When receiving the promise request, each replica checks its Paxos state to decide if it can safely respond to the request, depending on the promises it has previously given out. If the replica is able to give the promise (i.e., passes the proposal number check), it will first persist its promise (the proposal number _n_) on disk and reply with a promise response. If the replica has been previously written (i.e., accepted a write request), it needs to include the previously written value along with the proposal number used in that write request into the promise response itâs about to send out. +When receiving the promise request, each replica checks its Paxos state to decide if it can safely respond to the request, depending on the promises it has previously given out. If the replica is able to give the promise (i.e., passes the proposal number check), it will first persist its promise (the proposal number _n_) on disk and reply with a promise response. If the replica has been previously written (i.e., accepted a write request), it needs to include the previously written value along with the proposal number used in that write request into the promise response it's about to send out. -Upon receiving promise responses from a [quorum](https://en.wikipedia.org/wiki/Quorum_%28distributed_computing%29) of replicas, the coordinator first checks if there exist any previously written value from those responses. The append operation cannot continue if a previously written value is found because itâs likely that a value has already been agreed on for that log entry. This is one of the key ideas in Paxos: restrict the value that can be written to ensure consistency. +Upon receiving promise responses from a [quorum](https://en.wikipedia.org/wiki/Quorum_%28distributed_computing%29) of replicas, the coordinator first checks if there exist any previously written value from those responses. The append operation cannot continue if a previously written value is found because it's likely that a value has already been agreed on for that log entry. This is one of the key ideas in Paxos: restrict the value that can be written to ensure consistency. -If no previous written value is found, the coordinator broadcasts a write request to all replicas with value _X_ and proposal number _n_. On receiving the write request, each replica checks the promise it has given again, and replies with a write response if the write requestâs proposal number is equal to or larger than the proposal number it has promised. Once the coordinator receives write responses from a quorum of replicas, the append operation succeeds. +If no previous written value is found, the coordinator broadcasts a write request to all replicas with value _X_ and proposal number _n_. On receiving the write request, each replica checks the promise it has given again, and replies with a write response if the write request's proposal number is equal to or larger than the proposal number it has promised. Once the coordinator receives write responses from a quorum of replicas, the append operation succeeds. ### Optimizing append latency using Multi-Paxos @@ -62,7 +62,7 @@ Multi-Paxos has better performance if the leader is stable. The replicated log i ### Enabling local reads -As discussed above, in our implementation, each replica is both an acceptor and a learner. Treating each replica as a learner allows us to do local reads without involving other replicas. When a log entryâs value has been agreed, the coordinator will broadcast a _learned_ message to all replicas. Once a replica receives the learned message, it will set the learned bit in the corresponding log entry, indicating the value of that log entry has been agreed. We say a log entry is "learned" if its learned bit is set. The coordinator does not have to wait for replicasâ acknowledgments. +As discussed above, in our implementation, each replica is both an acceptor and a learner. Treating each replica as a learner allows us to do local reads without involving other replicas. When a log entry's value has been agreed, the coordinator will broadcast a _learned_ message to all replicas. Once a replica receives the learned message, it will set the learned bit in the corresponding log entry, indicating the value of that log entry has been agreed. We say a log entry is "learned" if its learned bit is set. The coordinator does not have to wait for replicas' acknowledgments. To perform a read, the log reader will directly look up the underlying local replica. If the corresponding log entry is learned, the reader can just return the value to the user. Otherwise, a full Paxos round is needed to discover the agreed value. We always make sure that the replica co-located with the elected coordinator always has all log entries learned. We achieve that by running full Paxos rounds for those unlearned log entries after the coordinator is elected. @@ -80,9 +80,9 @@ To avoid livelock (e.g., when two coordinators completing), we inject a randomly ## Automatic replica recovery -The algorithm described above has a critical vulnerability: if a replica loses its durable state (i.e., log files) due to either disk failure or operational error, that replica may cause inconsistency in the log if it is simply restarted and re-added to the group. The operator needs to stop the application on all hosts, copy the log files from the leaderâs host, and then restart the application. Note that the operator cannot copy the log files from an arbitrary replica because copying an unlearned log entry may falsely assemble a quorum for an incorrect value, leading to inconsistency. +The algorithm described above has a critical vulnerability: if a replica loses its durable state (i.e., log files) due to either disk failure or operational error, that replica may cause inconsistency in the log if it is simply restarted and re-added to the group. The operator needs to stop the application on all hosts, copy the log files from the leader's host, and then restart the application. Note that the operator cannot copy the log files from an arbitrary replica because copying an unlearned log entry may falsely assemble a quorum for an incorrect value, leading to inconsistency. -To avoid the need for operator intervention in this situation, the Mesos replicated log includes support for _auto recovery_. As long as a quorum of replicas is working properly, the users of the application wonât notice any difference. +To avoid the need for operator intervention in this situation, the Mesos replicated log includes support for _auto recovery_. As long as a quorum of replicas is working properly, the users of the application won't notice any difference. ### Non-voting replicas @@ -107,7 +107,7 @@ Here is our correctness argument. For a log entry at position _e_ where _e_ is l ### Auto initialization -Since we donât allow an empty replica (a replica in EMPTY status) to respond to requests from coordinators, that raises a question for bootstrapping because initially, each replica is empty. The replicated log provides two choices here. One choice is to use a tool (`mesos-log) to explicitly initialize the log on each replica by setting the replica's status to VOTING, but that requires an extra step when setting up an application. +Since we don't allow an empty replica (a replica in EMPTY status) to respond to requests from coordinators, that raises a question for bootstrapping because initially, each replica is empty. The replicated log provides two choices here. One choice is to use a tool (`mesos-log) to explicitly initialize the log on each replica by setting the replica's status to VOTING, but that requires an extra step when setting up an application. The other choice is to do automatic initialization. Our idea is: we allow a replica in EMPTY status to become VOTING immediately if it finds all replicas are in EMPTY status. This is based on the assumption that the only time _all_ replicas are in EMPTY status is during start-up. This may not be true if a catastrophic failure causes all replicas to lose their durable state, and that's exactly the reason we allow conservative users to disable auto-initialization. http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/upgrades.md ---------------------------------------------------------------------- diff --git a/docs/upgrades.md b/docs/upgrades.md index e7f95aa..c1e6524 100644 --- a/docs/upgrades.md +++ b/docs/upgrades.md @@ -526,8 +526,8 @@ In order to upgrade a running cluster: For agent endpoints: - * /state.json becomes /stateÏ - * /monitor/statistics.json becomes /monitor/statisticsÏ + * /state.json becomes /state + * /monitor/statistics.json becomes /monitor/statistics For both master and agent: http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/versioning.md ---------------------------------------------------------------------- diff --git a/docs/versioning.md b/docs/versioning.md index da87414..3ad1249 100644 --- a/docs/versioning.md +++ b/docs/versioning.md @@ -75,9 +75,9 @@ A given Mesos installation might host multiple versions of the same API i.e., Sc * To keep things simple, the stable version of the API will correspond to the major release version of Mesos. * For example, v1 of the API will be supported by Mesos release versions 1.0.0, 1.4.0, 1.20.0 etc. * vN version of the API might also be supported by release versions of N-1 series but the vN API is not considered stable until the last release version of N-1 series. - * For example, v2 of the API might be introduced in Mesos 1.12.0 release but it is only considered stable in Mesos 1.21.0 release if it is the last release of â1â series. Note that all Mesos 1.x.y versions will still support v1 of the API. + * For example, v2 of the API might be introduced in Mesos 1.12.0 release but it is only considered stable in Mesos 1.21.0 release if it is the last release of "1" series. Note that all Mesos 1.x.y versions will still support v1 of the API. * The API version is only bumped if we need to make a backwards [incompatible](#api-compatibility) API change. We will strive to support a given API version for at least a year. -* The deprecation clock for vN-1 API will start as soon as we release âN.0.0â version of Mesos. We will strive to give enough time (e.g., 6 months) for frameworks/operators to upgrade to vN API before we stop supporting vN-1 API. +* The deprecation clock for vN-1 API will start as soon as we release "N.0.0" version of Mesos. We will strive to give enough time (e.g., 6 months) for frameworks/operators to upgrade to vN API before we stop supporting vN-1 API. <a name="api-compatibility"></a> ### API Compatibility @@ -90,7 +90,7 @@ As an example, the following are considered "backwards compatible" changes for S * Adding new optional fields to existing requests to "/scheduler". * Adding new types of Events i.e., new types of chunks streamed on "/scheduler". * Adding new header fields to chunked response streamed on "/scheduler". -* Adding new fields (or changing the order of fields) to chunksâ body streamed on "/scheduler". +* Adding new fields (or changing the order of fields) to chunks' body streamed on "/scheduler". * Adding new API resources (e.g., "/foobar"). The following are considered backwards incompatible changes for Scheduler API: @@ -107,7 +107,7 @@ The following are considered backwards incompatible changes for Scheduler API: For regular releases, the work is done on the master branch. There are no feature branches but there will be release branches. -When it is time to cut a minor release, a new branch (e.g., 1.2.x) is created off the master branch. We chose âxâ instead of patch release number to disambiguate branch names from tag names. Then the first RC (-rc1) is tagged on the release branch. Subsequent RCs, in case the previous RCs fail testing, should be tagged on the release branch. +When it is time to cut a minor release, a new branch (e.g., 1.2.x) is created off the master branch. We chose 'x' instead of patch release number to disambiguate branch names from tag names. Then the first RC (-rc1) is tagged on the release branch. Subsequent RCs, in case the previous RCs fail testing, should be tagged on the release branch. Patch releases are also based off the release branches. Typically the fix for an issue that is affecting supported releases lands on the master branch and is then backported to the release branch(es). In rare cases, the fix might directly go into a release branch without landing on master (e.g., fix / issue is not applicable to master). @@ -117,7 +117,7 @@ Having a branch for each minor release reduces the amount of work a release mana ### API protobufs -Most APIs in Mesos accept protobuf messages with a corresponding JSON field mapping. To support multiple versions of the API, we decoupled the versioned protobufs backing the API from the âinternalâ protobufs used by the Mesos code. +Most APIs in Mesos accept protobuf messages with a corresponding JSON field mapping. To support multiple versions of the API, we decoupled the versioned protobufs backing the API from the "internal" protobufs used by the Mesos code. For example, the protobufs for the v1 Scheduler API are located at: http://git-wip-us.apache.org/repos/asf/mesos/blob/2241fe0c/docs/working-groups.md ---------------------------------------------------------------------- diff --git a/docs/working-groups.md b/docs/working-groups.md index ebf4776..b6a0b35 100644 --- a/docs/working-groups.md +++ b/docs/working-groups.md @@ -73,7 +73,7 @@ layout: documentation * communication: * irc: mesos-oversubscription * members: - * BartÅomiej PÅotka + * Bartlomiej Plotka * Jie Yu * Joris Van Remoortere * Niklas Nielsen
