You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by ti...@apache.org on 2016/01/19 18:46:07 UTC
svn commit: r1725575 [2/2] - in /mesos/site/publish: community/
community/user-groups/ documentation/latest/maintenance/
documentation/latest/networking-for-mesos-managed-containers/
documentation/latest/reconciliation/ documentation/latest/scheduler-h...
Modified: mesos/site/publish/documentation/scheduler-http-api/index.html
URL: http://svn.apache.org/viewvc/mesos/site/publish/documentation/scheduler-http-api/index.html?rev=1725575&r1=1725574&r2=1725575&view=diff
==============================================================================
--- mesos/site/publish/documentation/scheduler-http-api/index.html (original)
+++ mesos/site/publish/documentation/scheduler-http-api/index.html Tue Jan 19 17:46:07 2016
@@ -87,14 +87,14 @@
<h2>Overview</h2>
-<p>The scheduler interacts with Mesos via â/api/v1/schedulerâ endpoint hosted by the Mesos master. The fully qualified URL of the endpoint might look like:</p>
+<p>The scheduler interacts with Mesos via “/api/v1/scheduler” endpoint hosted by the Mesos master. The fully qualified URL of the endpoint might look like:</p>
<pre><code>http://masterhost:5050/api/v1/scheduler
</code></pre>
-<p>Note that we refer to this endpoint with its suffix “/scheduler” in the rest of this document. This endpoint accepts HTTP POST requests with data encoded as JSON (Content-Type: application/json) or binary Protobuf (Content-Type: application/x-protobuf). The first request that a scheduler sends to â/schedulerâ endpoint is called SUBSCRIBE and results in a streaming response (â200 OKâ status code with Transfer-Encoding: chunked). <strong>Schedulers are expected to keep the subscription connection open as long as possible (barring errors in network, software, hardware etc.) and incrementally process the response</strong> (NOTE: HTTP client libraries that can only parse the response after the connection is closed cannot be used). For the encoding used, please refer to <strong>Events</strong> section below.</p>
+<p>Note that we refer to this endpoint with its suffix “/scheduler” in the rest of this document. This endpoint accepts HTTP POST requests with data encoded as JSON (Content-Type: application/json) or binary Protobuf (Content-Type: application/x-protobuf). The first request that a scheduler sends to “/scheduler” endpoint is called SUBSCRIBE and results in a streaming response (“200 OK” status code with Transfer-Encoding: chunked). <strong>Schedulers are expected to keep the subscription connection open as long as possible (barring errors in network, software, hardware etc.) and incrementally process the response</strong> (NOTE: HTTP client libraries that can only parse the response after the connection is closed cannot be used). For the encoding used, please refer to <strong>Events</strong> section below.</p>
-<p>All the subsequent (non subscribe) requests to â/schedulerâ endpoint (see details below in <strong>Calls</strong> section) must be sent using a different connection(s) than the one being used for subscription. Master responds to these HTTP POST requests with â202 Acceptedâ status codes (or, for unsuccessful requests, with 4xx or 5xx status codes; details in later sections). The â202 Acceptedâ response means that a request has been accepted for processing, not that the processing of the request has been completed. The request might or might not be acted upon by Mesos (e.g., master fails during the processing of the request). Any asynchronous responses from these requests will be streamed on long-lived subscription connection.</p>
+<p>All the subsequent (non subscribe) requests to “/scheduler” endpoint (see details below in <strong>Calls</strong> section) must be sent using a different connection(s) than the one being used for subscription. Master responds to these HTTP POST requests with “202 Accepted” status codes (or, for unsuccessful requests, with 4xx or 5xx status codes; details in later sections). The “202 Accepted” response means that a request has been accepted for processing, not that the processing of the request has been completed. The request might or might not be acted upon by Mesos (e.g., master fails during the processing of the request). Any asynchronous responses from these requests will be streamed on long-lived subscription connection.</p>
<h2>Calls</h2>
@@ -119,8 +119,8 @@
<p>For example, a stream may look like:</p>
<pre><code>128\n
-{âtypeâ: âSUBSCRIBEDâ,âsubscribedâ: {âframework_idâ: {âvalueâ:â12220-3440-12532-2345â},...}104\n
-{âframework_idâ: {âvalueâ: â12220-3440-12532-2345â},...{âvalueâ : â12220-3440-12532-O12â},}208\n
+{"type": "SUBSCRIBED","subscribed": {"framework_id": {"value":"12220-3440-12532-2345"},...}104\n
+{"framework_id": {"value": "12220-3440-12532-2345"},...{"value" : "12220-3440-12532-O12"},}208\n
...
</code></pre>
@@ -141,7 +141,7 @@
<h3><a id="subscribe"></a>SUBSCRIBE</h3>
-<p>This is the first step in the communication process between the scheduler and the master. This is also to be considered as subscription to the â/schedulerâ events stream.</p>
+<p>This is the first step in the communication process between the scheduler and the master. This is also to be considered as subscription to the “/scheduler” events stream.</p>
<p>To subscribe with the master, the scheduler sends a HTTP POST request with encoded <code>SUBSCRIBE</code> message with the required FrameworkInfo. Note that if “subscribe.framework_info.id” is not set, master considers the scheduler as a new one and subscribes it by assigning it a FrameworkID. The HTTP response is a stream with RecordIO encoding, with the first event being <code>SUBSCRIBED</code> event (see details in <strong>Events</strong> section).</p>
@@ -155,15 +155,15 @@ Accept: application/json
Connection: close
{
- âtypeâ : âSUBSCRIBEâ,
+ "type" : "SUBSCRIBE",
- âsubscribeâ : {
- âframework_infoâ : {
- âuserâ : âfooâ,
- ânameâ : âExample HTTP Frameworkâ
+ "subscribe" : {
+ "framework_info" : {
+ "user" : "foo",
+ "name" : "Example HTTP Framework"
},
- âforceâ : true
+ "force" : true
}
}
@@ -175,22 +175,22 @@ Transfer-Encoding: chunked
<event length>
{
- âtypeâ : âSUBSCRIBEDâ,
- âsubscribedâ : {
- âframework_idâ : {âvalueâ:â12220-3440-12532-2345â},
+ "type" : "SUBSCRIBED",
+ "subscribed" : {
+ "framework_id" : {"value":"12220-3440-12532-2345"},
"heartbeat_interval_seconds" : 15
}
}
<more events>
</code></pre>
-<p>Alternatively, if âsubscribe.framework_info.idâ is set, master considers this a request from an already subscribed scheduler reconnecting after a disconnection (e.g., due to failover or network disconnection) and responds with <code>SUBSCRIBED</code> event containing the same FrameworkID. The âsubscribe.forceâ field describes how the master reacts when multiple scheduler instances (with the same framework id) attempt to subscribe with the master at the same time (e.g., due to network partition). See the semantics in <strong>Disconnections</strong> section below.</p>
+<p>Alternatively, if “subscribe.framework_info.id” is set, master considers this a request from an already subscribed scheduler reconnecting after a disconnection (e.g., due to failover or network disconnection) and responds with <code>SUBSCRIBED</code> event containing the same FrameworkID. The “subscribe.force” field describes how the master reacts when multiple scheduler instances (with the same framework id) attempt to subscribe with the master at the same time (e.g., due to network partition). See the semantics in <strong>Disconnections</strong> section below.</p>
-<p>NOTE: In the old version of the API, (re-)registered callbacks also included MasterInfo, which contained information about the master the driver currently connected to. With the new API, since schedulers explicitly subscribe with the leading master (see details below in <strong>Master Detection</strong> section), itâs not relevant anymore.</p>
+<p>NOTE: In the old version of the API, (re-)registered callbacks also included MasterInfo, which contained information about the master the driver currently connected to. With the new API, since schedulers explicitly subscribe with the leading master (see details below in <strong>Master Detection</strong> section), it’s not relevant anymore.</p>
<p>If subscription fails for whatever reason (e.g., invalid request), a HTTP 4xx response is returned with the error message as part of the body and the connection is closed.</p>
-<p>Scheduler must make additional HTTP requests to the â/schedulerâ endpoint only after it has opened a persistent connection to it by sending a <code>SUBSCRIBE</code> request and received a <code>SUBSCRIBED</code> response. Calls made without subscription will result in a â403 Forbiddenâ instead of a â202 Acceptedâ response. A scheduler might also receive a â400 Bad Requestâ response if the HTTP request is malformed (e.g., malformed HTTP headers).</p>
+<p>Scheduler must make additional HTTP requests to the “/scheduler” endpoint only after it has opened a persistent connection to it by sending a <code>SUBSCRIBE</code> request and received a <code>SUBSCRIBED</code> response. Calls made without subscription will result in a “403 Forbidden” instead of a “202 Accepted” response. A scheduler might also receive a “400 Bad Request” response if the HTTP request is malformed (e.g., malformed HTTP headers).</p>
<h3>TEARDOWN</h3>
@@ -203,8 +203,8 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âTEARDOWNâ,
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "TEARDOWN",
}
TEARDOWN Response:
@@ -213,7 +213,7 @@ HTTP/1.1 202 Accepted
<h3>ACCEPT</h3>
-<p>Sent by the scheduler when it accepts offer(s) sent by the master. The <code>ACCEPT</code> request includes the type of operations (e.g., launch task, reserve resources, create volumes) that the scheduler wants to perform on the offers. Note that until the scheduler replies (accepts or declines) to an offer, its resources are considered allocated to the framework. Also, any of the offerâs resources not used in the <code>ACCEPT</code> call (e.g., to launch a task) are considered declined and might be reoffered to other frameworks. In other words, the same <code>OfferID</code> cannot be used in more than one <code>ACCEPT</code> call. These semantics might change when we add new features to Mesos (e.g., persistence, reservations, optimistic offers, resizeTask, etc.).</p>
+<p>Sent by the scheduler when it accepts offer(s) sent by the master. The <code>ACCEPT</code> request includes the type of operations (e.g., launch task, reserve resources, create volumes) that the scheduler wants to perform on the offers. Note that until the scheduler replies (accepts or declines) to an offer, its resources are considered allocated to the framework. Also, any of the offer’s resources not used in the <code>ACCEPT</code> call (e.g., to launch a task) are considered declined and might be reoffered to other frameworks. In other words, the same <code>OfferID</code> cannot be used in more than one <code>ACCEPT</code> call. These semantics might change when we add new features to Mesos (e.g., persistence, reservations, optimistic offers, resizeTask, etc.).</p>
<pre><code>ACCEPT Request (JSON):
POST /api/v1/scheduler HTTP/1.1
@@ -222,15 +222,15 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âACCEPTâ,
- âacceptâ : {
- âoffer_idsâ : [
- {âvalueâ : â12220-3440-12532-O12â},
- {âvalueâ : â12220-3440-12532-O12â}
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "ACCEPT",
+ "accept" : {
+ "offer_ids" : [
+ {"value" : "12220-3440-12532-O12"},
+ {"value" : "12220-3440-12532-O12"}
],
- âoperationsâ : [ {âtypeâ : âLAUNCHâ, âlaunchâ : {...}} ],
- âfiltersâ : {...}
+ "operations" : [ {"type" : "LAUNCH", "launch" : {...}} ],
+ "filters" : {...}
}
}
@@ -249,14 +249,14 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âDECLINEâ,
- âdeclineâ : {
- âoffer_idsâ : [
- {âvalueâ : â12220-3440-12532-O12â},
- {âvalueâ : â12220-3440-12532-O13â}
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "DECLINE",
+ "decline" : {
+ "offer_ids" : [
+ {"value" : "12220-3440-12532-O12"},
+ {"value" : "12220-3440-12532-O13"}
],
- âfiltersâ : {...}
+ "filters" : {...}
}
}
@@ -275,8 +275,8 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âREVIVEâ,
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "REVIVE",
}
REVIVE Response:
@@ -294,11 +294,11 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âKILLâ,
- âkillâ : {
- âtask_idâ : {âvalueâ : â12220-3440-12532-my-taskâ},
- âagent_idâ : {âvalueâ : â12220-3440-12532-S1233â}
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "KILL",
+ "kill" : {
+ "task_id" : {"value" : "12220-3440-12532-my-task"},
+ "agent_id" : {"value" : "12220-3440-12532-S1233"}
}
}
@@ -308,7 +308,7 @@ HTTP/1.1 202 Accepted
<h3>SHUTDOWN</h3>
-<p>Sent by the scheduler to shutdown a specific custom executor (NOTE: This is a new call that was not present in the old API). When an executor gets a shutdown event, it is expected to kill all its tasks (and send <code>TASK_KILLED</code> updates) and terminate. If an executor doesnât terminate within a certain timeout (configurable via â–executor_shutdown_grace_periodâ agent flag), the agent will forcefully destroy the container (executor and its tasks) and transitions its active tasks to <code>TASK_LOST</code>.</p>
+<p>Sent by the scheduler to shutdown a specific custom executor (NOTE: This is a new call that was not present in the old API). When an executor gets a shutdown event, it is expected to kill all its tasks (and send <code>TASK_KILLED</code> updates) and terminate. If an executor doesn’t terminate within a certain timeout (configurable via “–executor_shutdown_grace_period” agent flag), the agent will forcefully destroy the container (executor and its tasks) and transitions its active tasks to <code>TASK_LOST</code>.</p>
<pre><code>SHUTDOWN Request (JSON):
POST /api/v1/scheduler HTTP/1.1
@@ -317,11 +317,11 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âSHUTDOWNâ,
- âshutdownâ : {
- âexecutor_idâ : {âvalueâ : â123450-2340-1232-my-executorâ},
- âagent_idâ : {âvalueâ : â12220-3440-12532-S1233â}
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "SHUTDOWN",
+ "shutdown" : {
+ "executor_id" : {"value" : "123450-2340-1232-my-executor"},
+ "agent_id" : {"value" : "12220-3440-12532-S1233"}
}
}
@@ -331,7 +331,7 @@ HTTP/1.1 202 Accepted
<h3>ACKNOWLEDGE</h3>
-<p>Sent by the scheduler to acknowledge a status update. Note that with the new API, schedulers are responsible for explicitly acknowledging the receipt of status updates that have âstatus.uuid()â set. These status updates are reliably retried until they are acknowledged by the scheduler. The scheduler must not acknowledge status updates that do not have âstatus.uuid()â set as they are not retried. “uuid” is raw bytes encoded in Base64.</p>
+<p>Sent by the scheduler to acknowledge a status update. Note that with the new API, schedulers are responsible for explicitly acknowledging the receipt of status updates that have “status.uuid()” set. These status updates are reliably retried until they are acknowledged by the scheduler. The scheduler must not acknowledge status updates that do not have “status.uuid()” set as they are not retried. “uuid” is raw bytes encoded in Base64.</p>
<pre><code>ACKNOWLEDGE Request (JSON):
POST /api/v1/scheduler HTTP/1.1
@@ -340,12 +340,12 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âACKNOWLEDGEâ,
- âacknowledgeâ : {
- âagent_idâ : {âvalueâ : â12220-3440-12532-S1233â},
- âtask_idâ : {âvalueâ : â12220-3440-12532-my-taskâ},
- âuuidâ : âjhadf73jhakdlfha723adfâ
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "ACKNOWLEDGE",
+ "acknowledge" : {
+ "agent_id" : {"value" : "12220-3440-12532-S1233"},
+ "task_id" : {"value" : "12220-3440-12532-my-task"},
+ "uuid" : "jhadf73jhakdlfha723adf"
}
}
@@ -364,12 +364,12 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âRECONCILEâ,
- âreconcileâ : {
- âtasksâ : [
- { âtask_idâ : { âvalueâ : â312325â },
- âagent_idâ : { âvalueâ : â123535â }
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "RECONCILE",
+ "reconcile" : {
+ "tasks" : [
+ { "task_id" : { "value" : "312325" },
+ "agent_id" : { "value" : "123535" }
}
]
}
@@ -390,12 +390,12 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âMESSAGEâ,
- âmessageâ : {
- âagent_idâ : {âvalueâ : â12220-3440-12532-S1233â},
- âexecutor_idâ : {âvalueâ : âmy-framework-executorâ},
- âdataâ : âadaf838jahd748jnaldfâ
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "MESSAGE",
+ "message" : {
+ "agent_id" : {"value" : "12220-3440-12532-S1233"},
+ "executor_id" : {"value" : "my-framework-executor"},
+ "data" : "adaf838jahd748jnaldf"
}
}
@@ -414,12 +414,12 @@ Host: masterhost:5050
Content-Type: application/json
{
- âframework_idâ : {âvalueâ : â12220-3440-12532-2345â},
- âtypeâ : âREQUESTâ,
- ârequestsâ : [
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "REQUEST",
+ "requests" : [
{
- âagent_idâ : {âvalueâ : â12220-3440-12532-S1233â},
- âresourcesâ : {}
+ "agent_id" : {"value" : "12220-3440-12532-S1233"},
+ "resources" : {}
},
]
}
@@ -430,7 +430,7 @@ HTTP/1.1 202 Accepted
<h2>Events</h2>
-<p>Scheduler is expected to keep a <strong>persistent</strong> connection open to â/schedulerâ endpoint even after getting a SUBSCRIBED HTTP Response event. This is indicated by âConnection: keep-aliveâ and âTransfer-Encoding: chunkedâ headers with <em>no</em> âContent-Lengthâ header set. All subsequent events that are relevant to this framework generated by Mesos are streamed on this connection. Master encodes each Event in RecordIO format, i.e., string representation of length of the event in bytes followed by JSON or binary Protobuf (possibly compressed) encoded event. Note that the value of length will never be â0â and the size of the length will be the size of unsigned integer (i.e., 64 bits). Also, note that the RecordIO encoding should be decoded by the scheduler whereas the underlying HTTP chunked encoding is typically invisible at the application (scheduler) layer. The type of content encoding used for the events will be d
etermined by the accept header of the POST request (e.g., Accept: application/json).</p>
+<p>Scheduler is expected to keep a <strong>persistent</strong> connection open to “/scheduler” endpoint even after getting a SUBSCRIBED HTTP Response event. This is indicated by “Connection: keep-alive” and “Transfer-Encoding: chunked” headers with <em>no</em> “Content-Length” header set. All subsequent events that are relevant to this framework generated by Mesos are streamed on this connection. Master encodes each Event in RecordIO format, i.e., string representation of length of the event in bytes followed by JSON or binary Protobuf (possibly compressed) encoded event. Note that the value of length will never be ‘0’ and the size of the length will be the size of unsigned integer (i.e., 64 bits). Also, note that the RecordIO encoding should be decoded by the scheduler whereas the underlying HTTP chunked encoding is typically invisible at the application (scheduler) layer. The type of content encoding used for the events
will be determined by the accept header of the POST request (e.g., Accept: application/json).</p>
<p>The following events are currently sent by the master. The canonical source of this information is at <a href="include/mesos/v1/scheduler/scheduler.proto">scheduler.proto</a>. Note that when sending JSON encoded events, master encodes raw bytes in Base64 and strings in UTF-8.</p>
@@ -445,16 +445,16 @@ HTTP/1.1 202 Accepted
<pre><code>OFFERS Event (JSON)
<event-length>
{
- âtypeâ : âOFFERSâ,
- âoffersâ : [
+ "type" : "OFFERS",
+ "offers" : [
{
- âoffer_idâ:{âvalueâ: â12214-23523-O235235â},
- âframework_idâ:{âvalueâ: â12124-235325-32425â},
- âagent_idâ:{âvalueâ: â12325-23523-S23523â},
- âhostnameâ:âagent.hostâ,
- âresourcesâ:[...],
- âattributesâ:[...],
- âexecutor_idsâ:[]
+ "offer_id":{"value": "12214-23523-O235235"},
+ "framework_id":{"value": "12124-235325-32425"},
+ "agent_id":{"value": "12325-23523-S23523"},
+ "hostname":"agent.host",
+ "resources":[...],
+ "attributes":[...],
+ "executor_ids":[]
}
]
}
@@ -467,9 +467,9 @@ HTTP/1.1 202 Accepted
<pre><code>RESCIND Event (JSON)
<event-length>
{
- âtypeâ : âRESCINDâ,
- ârescindâ : {
- âoffer_idâ : { âvalueâ : â12214-23523-O235235â}
+ "type" : "RESCIND",
+ "rescind" : {
+ "offer_id" : { "value" : "12214-23523-O235235"}
}
}
</code></pre>
@@ -482,13 +482,13 @@ HTTP/1.1 202 Accepted
<event-length>
{
- âtypeâ : âUPDATEâ,
- âupdateâ : {
- âstatusâ : {
- âtask_idâ : { âvalueâ : â12344-my-taskâ},
- âstateâ : âTASK_RUNNINGâ,
- âsourceâ : âSOURCE_EXECUTORâ,
- âuuidâ : âadfadfadbhgvjayd23r2uahjâ,
+ "type" : "UPDATE",
+ "update" : {
+ "status" : {
+ "task_id" : { "value" : "12344-my-task"},
+ "state" : "TASK_RUNNING",
+ "source" : "SOURCE_EXECUTOR",
+ "uuid" : "adfadfadbhgvjayd23r2uahj",
"bytes" : "uhdjfhuagdj63d7hadkf"
}
@@ -504,11 +504,11 @@ HTTP/1.1 202 Accepted
<event-length>
{
- âtypeâ : âMESSAGEâ,
- âmessageâ : {
- âagent_idâ : { âvalueâ : â12214-23523-S235235â},
- âexecutor_idâ : { âvalueâ : â12214-23523-my-executorâ},
- âdataâ : âadfadf3t2wa3353dfadfâ
+ "type" : "MESSAGE",
+ "message" : {
+ "agent_id" : { "value" : "12214-23523-S235235"},
+ "executor_id" : { "value" : "12214-23523-my-executor"},
+ "data" : "adfadf3t2wa3353dfadf"
}
}
</code></pre>
@@ -521,11 +521,11 @@ HTTP/1.1 202 Accepted
<event-length>
{
- âtypeâ : âFAILUREâ,
- âfailureâ : {
- âagent_idâ : { âvalueâ : â12214-23523-S235235â},
- âexecutor_idâ : { âvalueâ : â12214-23523-my-executorâ},
- âstatusâ : 1
+ "type" : "FAILURE",
+ "failure" : {
+ "agent_id" : { "value" : "12214-23523-S235235"},
+ "executor_id" : { "value" : "12214-23523-my-executor"},
+ "status" : 1
}
}
</code></pre>
@@ -538,8 +538,8 @@ HTTP/1.1 202 Accepted
<event-length>
{
- âtypeâ : âERRORâ,
- âmessageâ : âFramework is not authorizedâ
+ "type" : "ERROR",
+ "message" : "Framework is not authorized"
}
</code></pre>
@@ -551,38 +551,38 @@ HTTP/1.1 202 Accepted
<event-length>
{
- âtypeâ : âHEARTBEATâ,
+ "type" : "HEARTBEAT",
}
</code></pre>
<h2>Disconnections</h2>
-<p>Master considers a scheduler disconnected if the persistent subscription connection (opened via <code>SUBSCRIBE</code> request) to â/schedulerâ breaks. The connection could break for several reasons, e.g., scheduler restart, scheduler failover, network error. Note that the master doesnât keep track of non-subscription connection(s) to
-â/schedulerâ because it is not expected to be a persistent connection.</p>
+<p>Master considers a scheduler disconnected if the persistent subscription connection (opened via <code>SUBSCRIBE</code> request) to “/scheduler” breaks. The connection could break for several reasons, e.g., scheduler restart, scheduler failover, network error. Note that the master doesn’t keep track of non-subscription connection(s) to
+“/scheduler” because it is not expected to be a persistent connection.</p>
-<p>If master realizes that the subscription connection is broken, it marks the scheduler as âdisconnectedâ and starts a failover timeout (failover timeout is part of FrameworkInfo). It also drops any pending events in its queue. Additionally, it rejects subsequent non-subscribe HTTP requests to â/schedulerâ with â403 Forbiddenâ, until the scheduler subscribes again with â/schedulerâ. If the scheduler <em>does not</em> re-subscribe within the failover timeout, the master considers the scheduler gone forever and shuts down all its executors, thus killing all its tasks. Therefore, all production schedulers are recommended to use a high value (e.g., 4 weeks) for the failover timeout.</p>
+<p>If master realizes that the subscription connection is broken, it marks the scheduler as “disconnected” and starts a failover timeout (failover timeout is part of FrameworkInfo). It also drops any pending events in its queue. Additionally, it rejects subsequent non-subscribe HTTP requests to “/scheduler” with “403 Forbidden”, until the scheduler subscribes again with “/scheduler”. If the scheduler <em>does not</em> re-subscribe within the failover timeout, the master considers the scheduler gone forever and shuts down all its executors, thus killing all its tasks. Therefore, all production schedulers are recommended to use a high value (e.g., 4 weeks) for the failover timeout.</p>
-<p>NOTE: To force shutdown a framework before the framework timeout elapses (e.g., during framework development and testing), either the framework can send <code>TEARDOWN</code> call (part of Scheduler API) or an operator can use the â/master/teardownâ endpoint (part of Operator API).</p>
+<p>NOTE: To force shutdown a framework before the framework timeout elapses (e.g., during framework development and testing), either the framework can send <code>TEARDOWN</code> call (part of Scheduler API) or an operator can use the “/master/teardown” endpoint (part of Operator API).</p>
-<p>If the scheduler realizes that its subscription connection to â/schedulerâ is broken, it should attempt to open a new persistent connection to the
-â/schedulerâ (on possibly new master based on the result of master detection) and resubscribe. It should not send new non-subscribe HTTP requests to â/schedulerâ unless it gets a <code>SUBSCRIBED</code> event; such requests will result in â403 Forbiddenâ.</p>
+<p>If the scheduler realizes that its subscription connection to “/scheduler” is broken, it should attempt to open a new persistent connection to the
+“/scheduler” (on possibly new master based on the result of master detection) and resubscribe. It should not send new non-subscribe HTTP requests to “/scheduler” unless it gets a <code>SUBSCRIBED</code> event; such requests will result in “403 Forbidden”.</p>
<p>If the master does not realize that the subscription connection is broken, but the scheduler realizes it, the scheduler might open a new persistent connection to
-â/schedulerâ via <code>SUBSCRIBE</code>. In this case, the semantics depend on the value of <code>subscribe.force</code>. If set to true, master closes the existing subscription connection and allows subscription on the new connection. If set to false, the new connection attempt is disallowed in favor of the existing connection. The invariant here is that, only one persistent subscription connection for a given FrameworkID is allowed on the master. For HA schedulers, it is recommended that a scheduler instance set <code>subscribe.force</code> to true only when it just got elected and set it to false for all subsequent reconnection attempts (e.g, due to disconnection or master failover).</p>
+“/scheduler” via <code>SUBSCRIBE</code>. In this case, the semantics depend on the value of <code>subscribe.force</code>. If set to true, master closes the existing subscription connection and allows subscription on the new connection. If set to false, the new connection attempt is disallowed in favor of the existing connection. The invariant here is that, only one persistent subscription connection for a given FrameworkID is allowed on the master. For HA schedulers, it is recommended that a scheduler instance set <code>subscribe.force</code> to true only when it just got elected and set it to false for all subsequent reconnection attempts (e.g, due to disconnection or master failover).</p>
<h3>Network partitions</h3>
-<p>In the case of a network partition, the subscription connection between the scheduler and master might not necessarily break. To be able to detect this scenario, master periodically (e.g., 15s) sends <code>HEARTBEAT</code> events (similar in vein to Twitterâs Streaming API). If a scheduler doesnât receive a bunch (e.g., 5) of these heartbeats within a time window, it should immediately disconnect and try to re-subscribe. It is highly recommended for schedulers to use an exponential backoff strategy (e.g., upto a maximum of 15s) to avoid overwhelming the master while reconnecting. Schedulers can use a similar timeout (e.g., 75s) for receiving responses to any HTTP requests.</p>
+<p>In the case of a network partition, the subscription connection between the scheduler and master might not necessarily break. To be able to detect this scenario, master periodically (e.g., 15s) sends <code>HEARTBEAT</code> events (similar in vein to Twitter’s Streaming API). If a scheduler doesn’t receive a bunch (e.g., 5) of these heartbeats within a time window, it should immediately disconnect and try to re-subscribe. It is highly recommended for schedulers to use an exponential backoff strategy (e.g., upto a maximum of 15s) to avoid overwhelming the master while reconnecting. Schedulers can use a similar timeout (e.g., 75s) for receiving responses to any HTTP requests.</p>
<h2>Master detection</h2>
<p>Mesos has a high-availability mode that uses multiple Mesos masters; one active master (called the leader or leading master) and several standbys in case it fails. The masters elect the leader, with ZooKeeper coordinating the election. For more details please refer to the <a href="/documentation/latest//documentation/latest/high-availability/">documentation</a>.</p>
-<p>Schedulers are expected to make HTTP requests to the leading master. If requests are made to a non-leading master a âHTTP 307 Temporary Redirectâ will be received with the âLocationâ header pointing to the leading master.</p>
+<p>Schedulers are expected to make HTTP requests to the leading master. If requests are made to a non-leading master a “HTTP 307 Temporary Redirect” will be received with the “Location” header pointing to the leading master.</p>
<p>Example subscription workflow with redirection when the scheduler hits a non-leading master.</p>
-<pre><code>Scheduler â Master
+<pre><code>Scheduler -> Master
POST /api/v1/scheduler HTTP/1.1
Host: masterhost1:5050
@@ -591,19 +591,19 @@ Accept: application/json
Connection: keep-alive
{
- âframework_infoâ : {
- âuserâ : âfooâ,
- ânameâ : âExample HTTP Frameworkâ
+ "framework_info" : {
+ "user" : "foo",
+ "name" : "Example HTTP Framework"
},
- âtypeâ : âSUBSCRIBEâ
+ "type" : "SUBSCRIBE"
}
-Master â Scheduler
+Master -> Scheduler
HTTP/1.1 307 Temporary Redirect
Location: masterhost2:5050
-Scheduler â Master
+Scheduler -> Master
POST /api/v1/scheduler HTTP/1.1
Host: masterhost2:5050
@@ -612,15 +612,15 @@ Accept: application/json
Connection: keep-alive
{
- âframework_infoâ : {
- âuserâ : âfooâ,
- ânameâ : âExample HTTP Frameworkâ
+ "framework_info" : {
+ "user" : "foo",
+ "name" : "Example HTTP Framework"
},
- âtypeâ : âSUBSCRIBEâ
+ "type" : "SUBSCRIBE"
}
</code></pre>
-<p>If the scheduler knows the list of masterâs hostnames for a cluster, it could use this mechanism to find the leading master to subscribe with. Alternatively, the scheduler could use a pure language library that detects the leading master given a ZooKeeper (or etcd) URL. For a <code>C++</code> library that does ZooKeeper based master detection please look at <code>src/scheduler/scheduler.cpp</code>.</p>
+<p>If the scheduler knows the list of master’s hostnames for a cluster, it could use this mechanism to find the leading master to subscribe with. Alternatively, the scheduler could use a pure language library that detects the leading master given a ZooKeeper (or etcd) URL. For a <code>C++</code> library that does ZooKeeper based master detection please look at <code>src/scheduler/scheduler.cpp</code>.</p>
</div>
</div>
Modified: mesos/site/publish/documentation/testing-patterns/index.html
URL: http://svn.apache.org/viewvc/mesos/site/publish/documentation/testing-patterns/index.html?rev=1725575&r1=1725574&r2=1725575&view=diff
==============================================================================
--- mesos/site/publish/documentation/testing-patterns/index.html (original)
+++ mesos/site/publish/documentation/testing-patterns/index.html Tue Jan 19 17:46:07 2016
@@ -89,7 +89,7 @@
<p>Some events in Mesos are separated by certain timeouts, for example framework registration attempts. Simple waiting for such events to fire leads to blocking the test thread for the duration of the associated timeout. This increases the duration of <code>make check</code> for no good reason.</p>
-<p>If an event is triggered by an act of processing a message from an actor’s mailbox, it can be expedited with the help of libprocess' <code>Clock</code> routines. Delayed messages are maintained in sorted order by their due time and are dispatched â i.e. pushed into destination mailboxes â when this time comes. An important bit here is that time is driven by the internal libprocess clock. We can shift this clock into the future by calling <code>Clock::advance(<duration>)</code>, rendering certain front messages in the collection due now. These messages are dispatched instantly, effectively overriding the associated event’s timeout.</p>
+<p>If an event is triggered by an act of processing a message from an actor’s mailbox, it can be expedited with the help of libprocess' <code>Clock</code> routines. Delayed messages are maintained in sorted order by their due time and are dispatched - i.e. pushed into destination mailboxes - when this time comes. An important bit here is that time is driven by the internal libprocess clock. We can shift this clock into the future by calling <code>Clock::advance(<duration>)</code>, rendering certain front messages in the collection due now. These messages are dispatched instantly, effectively overriding the associated event’s timeout.</p>
<p><strong>NOTE</strong>: Without calling <code>Clock::settle()</code> there is no guarantee a dispatched message has been already processed.</p>