[GitHub] mesos pull request: Upgrade zookeeper to 3.4.8.
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/93#discussion_r58094904 --- Diff: 3rdparty/Makefile.am --- @@ -51,7 +51,7 @@ EXTRA_DIST = \ EXTRA_DIST += \ $(LEVELDB).patch -# We need to patch ZooKeeper in order to get 3.4.5 to compile on +# We need to patch ZooKeeper in order to get 3.4.8 to compile on # OS X 10.10. See: MESOS-1797. --- End diff -- Does this comment still apply? AFAICT MESOS-1797 doesn't apply to ZK 3.4.8 since that issue has been resolved in ZK 3.4.7. Looks all the patch does is apply PPC specific fixes for which you already submitted a review https://reviews.apache.org/r/45376/. I would recommend to kill the zookeper.patch stuff in this review altogether since 3.4.8 doesn't need any patches per se. Then in https://reviews.apache.org/r/45376/ you can add back the patch stuff and mention that you need the patch to compile it on PPC. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos pull request: Upgrade zookeeper to 3.4.8.
Github user vinodkone commented on the pull request: https://github.com/apache/mesos/pull/93#issuecomment-204558214 libev is committed. You can rebase it now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos issue #36: replace unsafe "find | xargs" with "find -exec"
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/36 I think this broke the ReviewBot. See https://issues.apache.org/jira/browse/MESOS-5958 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos pull request #168: Update contributors.yaml for gradywang.
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/168#discussion_r81236751
--- Diff: docs/contributors.yaml ---
@@ -402,13 +402,14 @@
jira_user: yanyanhu
reviewboard_user: yanyanhu
-- name: Yong Qiao Wang
--- End diff --
If your name and reviewboard username have also changed along with your
affiliation, then it's probably worth to have two different entries in the YAML
file.
```
- name: Yong Qiao Wang
affiliations:
- {organization: IBM}
emails:
- yq...@cn.ibm.com
jira_user: gradywang
reviewboard_user: JamesYongQiaoWang
- name: Yongqiao Wang
affiliations:
- {organization: Huawei}
emails:
- grady.w...@foxmail.com
jira_user: gradywang
reviewboard_user: gradywang
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] mesos pull request #168: Update contributors.yaml for gradywang.
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/168#discussion_r82063596 --- Diff: docs/contributors.yaml --- @@ -402,13 +402,14 @@ jira_user: yanyanhu reviewboard_user: yanyanhu -- name: Yong Qiao Wang --- End diff -- oh ok. then a single entry sounds fine. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos pull request #168: Update contributors.yaml for gradywang.
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/168#discussion_r79516117
--- Diff: docs/contributors.yaml ---
@@ -402,13 +402,13 @@
jira_user: yanyanhu
reviewboard_user: yanyanhu
-- name: Yong Qiao Wang
+- name: Yongqiao Wang
affiliations:
-- {organization: IBM}
--- End diff --
Instead of removing your old affiliation (IBM) completely, can you add an
"end_date" to it? That way your contributions while you were employed at IBM,
will be attributed correctly. See my affiliation above for an example.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] mesos issue #171: Update cli.py
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/171 Can you close this in favor of the review request? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos pull request #:
Github user vinodkone commented on the pull request: https://github.com/apache/mesos/commit/aeaec8940c7dd8e17e379fc7aa03fbce60d77b20#commitcomment-19363756 @kamilchm can you file a ticket on issues.apache.org? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos issue #190: Ensure curl is present on Ubuntu
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/190 Thanks for the PR. @jieyu what's our recommendation regarding curl dependency? I remember there was a discussion in the mailing list sometime back. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos issue #205: Clarify existence of FrameworkID in SUBSCRIBE calls.
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/205 @hatred still planning to review this? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] mesos pull request #247: Fixed reference to Mesos paper in the documentation...
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/247#discussion_r148613763 --- Diff: docs/architecture.md --- @@ -34,4 +34,4 @@ In addition, this resource offer process repeats when tasks finish and new resou While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality. -You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf). +You can also read much more about the Mesos architecture in this [technical paper](http://mesos.apache.org/assets/papers/nsdi_mesos.pdf). --- End diff -- https://www.usenix.org/conference/nsdi11/mesos-platform-fine-grained-resource-sharing-data-center is even better because it has links to video, audio, slides and the paper. ---
[GitHub] mesos pull request #247: Fixed reference to Mesos paper in the documentation...
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/247#discussion_r148613391 --- Diff: docs/architecture.md --- @@ -34,4 +34,4 @@ In addition, this resource offer process repeats when tasks finish and new resou While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to **reject** offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality. -You can also read much more about the Mesos architecture in this [technical paper](http://mesos.berkeley.edu/mesos_tech_report.pdf). +You can also read much more about the Mesos architecture in this [technical paper](http://mesos.apache.org/assets/papers/nsdi_mesos.pdf). --- End diff -- I think you can use "https://www.usenix.org/legacy/events/nsdi11/tech/full_papers/Hindman.pdf; ---
[GitHub] mesos pull request #294: FaultDomain, conventions for additional hierarchy.
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/294#discussion_r192161678
--- Diff: include/mesos/mesos.proto ---
@@ -827,6 +827,18 @@ message ExecutorInfo {
* in the same zone, in different zones in the same region, or in
* different regions. Note that all masters in a given Mesos cluster
* must be in the same region.
+ *
+ * Complex deployments may have additional levels of hierarchy: for
example,
+ * multiple racks might be grouped together into "halls" and multiple DCs
in
+ * the same geographical vicinity might be grouped together. As a
convention,
+ * the recommended way to represent additional levels of hierarchy is via
dot-
--- End diff --
We don't need to recommend "dot" right? It could be any delimiter that they
choose to have? As far as Mesos is concerned, it doesn't matter.
---
[GitHub] mesos issue #216: 1.3.x
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/216 @shendabin Can you please close/delete this PR? ---
[GitHub] mesos issue #213: Update vendored protobuf tar.gz to 3.2.0.
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/213 @zhitaoli Can you close this? Looks we are at protobuf 3.5 already in the repo. ---
[GitHub] mesos issue #255: Add curl examples to operator-http-api
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/255 @nhandler If you can update the PR, I'll commit it ASAP. ---
[GitHub] mesos issue #249: Update presentations.md
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/249 @packtpartner Can you close this please? ---
[GitHub] mesos issue #258: Update api-client-libraries.md
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/258 Thanks for the submission! Are you planning to use this in production? ---
[GitHub] mesos issue #255: Add curl examples to operator-http-api
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/255 @nhandler Thanks for doing this! Awesome. Do I take it that you tested all these commands? Also, is the EOF required in all the curl commands? ---
[GitHub] mesos issue #262: Updating reservation.md
Github user vinodkone commented on the issue: https://github.com/apache/mesos/pull/262 @mpark @bmahler Can you guys review? ---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/301#discussion_r204166164 --- Diff: docs/scheduler-http-api.md --- @@ -479,6 +479,32 @@ HTTP/1.1 202 Accepted ``` +### SUPPRESS +Sent by the scheduler when it doesn't need offers for a given set of its roles. When Mesos master receives this request, it will stop sending offers for the given set of roles to the framework. As a special case, if roles are not specified, all subscribed roles of this framework are suppressed. + +Note that master continues to send offers to other subscribed roles of this framework that are not suppressed. Also, status updates about tasks, executors and agents are not affected by this call and tasks will continue running for `FrameworkInfo.failover_timeout`. --- End diff -- I would remove `...and tasks will continue running for `FrameworkInfo.failover_timeout`` part. That timeout doesn't come into play at all during suppression. That will only come into play when a framework disconnects. ---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/301#discussion_r204167169
--- Diff: docs/scheduler-http-api.md ---
@@ -479,6 +479,32 @@ HTTP/1.1 202 Accepted
```
+### SUPPRESS
+Sent by the scheduler when it doesn't need offers for a given set of its
roles. When Mesos master receives this request, it will stop sending offers for
the given set of roles to the framework. As a special case, if roles are not
specified, all subscribed roles of this framework are suppressed.
+
+Note that master continues to send offers to other subscribed roles of
this framework that are not suppressed. Also, status updates about tasks,
executors and agents are not affected by this call and tasks will continue
running for `FrameworkInfo.failover_timeout`.
+
+If the scheduler wishes to receive offers for the suppressed roles again
(e.g., it needs to schedule new workloads), it can send `REVIVE` call.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+ "framework_id" : {"value" : "12220-3440-12532-2345"},
+ "type" : "SUPPRESS",
+ "suppress" : {"role": }
--- End diff --
This should be `roles` and not `role` since Mesos at least 1.3.0! And
`roles` takes an array of strings (i.e., roles) and not a single role.
---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/301#discussion_r201407700
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
HTTP/1.1 202 Accepted
```
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending
offers to the framework. When Mesos receives this request it will stop sending
offers to framework but the tasks will continue running for
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+ "framework_id": {"value" : "12220-3440-12532-2345"},
+ "type": "SUPPRESS"
+}
+
+SUPPRESS Response:
+HTTP/1.1 202 Accepted
+```
+
--- End diff --
While you are at it, can you also update the documentation about "REVIVE"
call below. I think it's a bit outdated now. Preferably in a different PR.
---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/301#discussion_r201401610 --- Diff: docs/scheduler-http-api.md --- @@ -128,6 +128,26 @@ TEARDOWN Response: HTTP/1.1 202 Accepted ``` +### SUPPRESS --- End diff -- Can you move this to #500 below #REQUEST section to preserve the call enum order? ---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request:
https://github.com/apache/mesos/pull/301#discussion_r201406742
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
HTTP/1.1 202 Accepted
```
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending
offers to the framework. When Mesos receives this request it will stop sending
offers to framework but the tasks will continue running for
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+ "framework_id": {"value" : "12220-3440-12532-2345"},
+ "type": "SUPPRESS"
+}
--- End diff --
Can you also include `roles` field here for completeness?
---
[GitHub] mesos pull request #301: Document SUPPRESS HTTP call [MESOS-7211]
Github user vinodkone commented on a diff in the pull request: https://github.com/apache/mesos/pull/301#discussion_r201406612 --- Diff: docs/scheduler-http-api.md --- @@ -128,6 +128,26 @@ TEARDOWN Response: HTTP/1.1 202 Accepted ``` +### SUPPRESS +Sent by the scheduler when it wants to inform Mesos master to stop sending offers to the framework. When Mesos receives this request it will stop sending offers to framework but the tasks will continue running for `FrameworkInfo.failover_timeout`. Once the framework has work to do, it can send again a `REVIVE` request. --- End diff -- How about: Sent by the scheduler when it doesn't need offers for a given set of its roles. When Mesos master receives this request, it will stop sending offers for the given set of roles to the framework. As a special case, if `roles` is not specified, all subscribed roles of this framework are suppressed. Note that master continues to send offers to other subscribed roles of this framework that are not suppressed. Also, status updates about tasks, executors and agents are not affected by this call. If the scheduler wishes to receive offers for the suppressed roles again (e.g., it needs to schedule new workloads), it can send `REVIVE` call. ---
