Skip to content

Conversation

@hellertime
Copy link
Contributor

@hellertime hellertime commented May 5, 2016

Add new boolean property: spark.mesos.ignoreDefaultRoleResources. When this property is set Spark will only accept resources from the role passed in the spark.mesos.role property. If spark.mesos.role has not been set, spark.mesos.ignoreDefaultRoleResources has no effect.

Additional unit tests added to MesosSchedulerBackendSuite, extending the original multi-role test suite.

@hellertime
Copy link
Contributor Author

@tnachen I'd like to request you review this change, since you are the author of the original mesos role code.

@tnachen
Copy link
Contributor

tnachen commented May 5, 2016

So from what I can see, what you really want is to only don't select resources from * role right?
Otherwise if you're getting offers from other roles you are already registered for those roles as well, which begs the question why are you registered with that role as well.

@tnachen
Copy link
Contributor

tnachen commented May 5, 2016

ok to test

@SparkQA
Copy link

SparkQA commented May 5, 2016

Test build #57891 has finished for PR 12933 at commit 48b4723.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hellertime
Copy link
Contributor Author

@tnachen exactly, I want to keep Spark from grabbing * roles, as in my use case I have a particular spark cluster that I want to isolate from other clusters.

@SparkQA
Copy link

SparkQA commented May 5, 2016

Test build #57905 has finished for PR 12933 at commit 8419664.

  • This patch fails MiMa tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hellertime
Copy link
Contributor Author

MiMa test died here:

/home/jenkins/workspace/SparkPullRequestBuilder@2/dev/mima: line 37: 18083 Aborted                 (core dumped) java -XX:MaxPermSize=1g -Xmx2g -cp "$TOOLS_CLASSPATH:$OLD_DEPS_CLASSPATH" org.apache.spark.tools.GenerateMIMAIgnore
[error] running /home/jenkins/workspace/SparkPullRequestBuilder@2/dev/mima -Pyarn -Phadoop-2.3 -Pkinesis-asl -Phive-thriftserver -Phive ; received return code 134
Attempting to post to Github...
 > Post successful.

I don't think this is due to my change, but I'm really not familiar with the MiMa test.

@tnachen
Copy link
Contributor

tnachen commented May 6, 2016

I see, I wonder besides the wildcard role if it ever makes sense to have two lists of roles, one set that you are registered with and another set you want to accept resources for, I cannot think of any possible scenario.
Perhaps we should just introduce one boolean flag that default takes wildcard role resources or not? spark.mesos.rejectWildcardRole or something better named?

@hellertime
Copy link
Contributor Author

I see that as a potential solution, however at some future point mesos will support frameworks which can hold multiple roles (MESOS-1763 😉) so perhaps leaving it in this form will ease that transition (though we'd then need to change the other property to spark.mesos.roles, so really its a wash).

@tnachen
Copy link
Contributor

tnachen commented May 6, 2016

Yes I am aware of multi roles, but not sure in what situation you would want to register with multiple roles but only use one role's resources?

@hellertime
Copy link
Contributor Author

hellertime commented May 6, 2016

True. So really the desired behavior is always just to ignore * resources. A boolean property would suffice here. What about spark.mesos.ignoreDefaultRoleResources, and have the property ignored if spark.mesos.role is unset?

@hellertime hellertime changed the title [Spark-15155][Mesos] Selectively accept Mesos resources by role [Spark-15155][Mesos] Optionally ignore default role resources May 6, 2016
@hellertime
Copy link
Contributor Author

I'm updating the title of the PR to reflect the change in approach. I think the boolean property will be sufficient.

@hellertime
Copy link
Contributor Author

Alright, I've modified the code to convert from a property which enumerated the accepted roles, to one which will simply ignore the default role when it is set.

I also removed one unit test, which was redundant with the test that checks we accepts all roles when spark.mesos.role is set.

@SparkQA
Copy link

SparkQA commented May 6, 2016

Test build #57989 has finished for PR 12933 at commit 5ea2f46.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hellertime
Copy link
Contributor Author

Rebasing against master.

@SparkQA
Copy link

SparkQA commented May 6, 2016

Test build #57993 has finished for PR 12933 at commit d2b7ad4.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@tnachen
Copy link
Contributor

tnachen commented Jun 2, 2016

@hellertime Can you rebase and submit again to rerun the tests?

@tnachen
Copy link
Contributor

tnachen commented Jun 22, 2016

@hellertime ping

@hellertime
Copy link
Contributor Author

Hi! Was busy with the day job. I didn't mean to let this slip! Absolutely will rebase and retest. Thanks.

Sent from my iPhone

On Jun 21, 2016, at 11:16 PM, Timothy Chen notifications@github.com wrote:

@hellertime ping


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@tnachen
Copy link
Contributor

tnachen commented Oct 8, 2016

@hellertime Are you able to rebase?

@hellertime
Copy link
Contributor Author

@tnachen rebased with master

@SparkQA
Copy link

SparkQA commented Oct 11, 2016

Test build #66740 has finished for PR 12933 at commit e81ff73.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hellertime
Copy link
Contributor Author

Fixed scala style error

@SparkQA
Copy link

SparkQA commented Oct 11, 2016

Test build #66741 has finished for PR 12933 at commit 181f207.

  • This patch fails to build.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Oct 12, 2016

Test build #66780 has finished for PR 12933 at commit 838dc77.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Oct 12, 2016

Test build #66811 has finished for PR 12933 at commit bbe908e.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Oct 12, 2016

Test build #66825 has finished for PR 12933 at commit 81e07c8.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hellertime
Copy link
Contributor Author

@tnachen I'm not sure what to do about this unit test failure. Running ./dev/run-tests on my system does not produce the error, and trying to just run the mesos suite with ./build/mvn -DwildcardSuites=org.apache.spark.scheduler.cluster.mesos test results in a successful build, it doesn't appear to actually run the test. Any advice on how to test this locally?

@tnachen
Copy link
Contributor

tnachen commented Oct 13, 2016

I just tried running it locally and I'm getting the same error. It seems like with your change that test is simply declining the offer.

@hellertime
Copy link
Contributor Author

You saw the error with ./dev/run-tests? Ok I'll figure this out.

Sent from my iPhone

On Oct 13, 2016, at 12:24 AM, Timothy Chen notifications@github.com wrote:

I just tried running it locally and I'm getting the same error. It seems like with your change that test is simply declining the offer.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Add new boolean property: `spark.mesos.ignoreDefaultRoleResources`.
When this property is set Spark will only accept resources from the role passed in the `spark.mesos.role` property.
If `spark.mesos.role` has not been set, `spark.mesos.ignoreDefaultRoleResources` has no effect.

Additional unit tests added to `MesosSchedulerBackendSuite`, extending the original multi-role test suite.
@SparkQA
Copy link

SparkQA commented Oct 13, 2016

Test build #66887 has finished for PR 12933 at commit d64b261.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@tnachen
Copy link
Contributor

tnachen commented Oct 13, 2016

I ran mvn test inside of the mesos folder.

On Thu, Oct 13, 2016 at 3:21 AM, Chris Heller notifications@github.com
wrote:

You saw the error with ./dev/run-tests? Ok I'll figure this out.

Sent from my iPhone

On Oct 13, 2016, at 12:24 AM, Timothy Chen notifications@github.com
wrote:

I just tried running it locally and I'm getting the same error. It seems
like with your change that test is simply declining the offer.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12933 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEGrAU4TKCiLBwMpDm7PmGsEm79tdoEks5qzgY0gaJpZM4IYBAd
.

case true if role.isDefined => Set(role)
case _ => Set(Some("*"), role)
}
val acceptedRoles = roles.flatten
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should move this log outside of this helper method, as there might be other context in the future that's calling this.

@tnachen
Copy link
Contributor

tnachen commented Dec 6, 2016

@srowen can you help review this? Besides my minor comment overall it looks fine with me.

Copy link
Member

@srowen srowen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only usefully comment on style and left a few comments

getResource(o.resources, "cpus") >= driverCpu &&
getResource(o.resources, "mem") >= driverMem
val acceptableResources = o.resources.asScala
.filter((r: Resource) => acceptedResourceRoles(r.getRole))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a style thing, but I think you'd generally just write (r => acceptedResourceRoles(r.getRole))

.filter((r: Resource) => acceptedResourceRoles(r.getRole))
.asJava
getResource(acceptableResources, "cpus") >= driverCpu &&
getResource(acceptableResources, "mem") >= driverMem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent this continuation 2 spaces to make it clear it's a continuation

* @param props Mesos driver description schedulerProperties map
*/
protected def getAcceptedResourceRoles(props: Map[String, String]): Set[String] = {
getAcceptedResourceRoles(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be my taste only but I'm finding this style hard to read.
props.get(...).map(_.toBoolean).getOrElse(false)? It's what I'd expect to see in the spark code base but don't know if it's objectively any better. Still I'd break this out into a val rather than squeeze this into a method arg

*/
private def getAcceptedResourceRoles(
ignoreDefaultRoleResources: Boolean,
role: Option[String]) = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems more readable:

val roles = if (ignoreDefaultRoleResources && role.isDefined) Set(role) else Set(Some("*"), role)

@HyukjinKwon
Copy link
Member

Hi @hellertime, this PR seems inactive for few months after the last review comments above. Would this be better closed if you are not currently able to work on this further maybe?

@asfgit asfgit closed this in ed338f7 Feb 17, 2017
zifeif2 pushed a commit to zifeif2/spark that referenced this pull request Nov 22, 2025
## What changes were proposed in this pull request?

This PR proposes to close stale PRs.

What I mean by "stale" here includes that there are some review comments by reviewers but the author looks inactive without any answer to them more than a month.

I left some comments roughly a week ago to ping and the author looks still inactive in these PR below

These below includes some PR suggested to be closed and a PR against another branch which seems obviously inappropriate.

Given the comments in the last three PRs below, they are probably worth being taken over by anyone who is interested in it.

Closes apache#7963
Closes apache#8374
Closes apache#11192
Closes apache#11374
Closes apache#11692
Closes apache#12243
Closes apache#12583
Closes apache#12620
Closes apache#12675
Closes apache#12697
Closes apache#12800
Closes apache#13715
Closes apache#14266
Closes apache#15053
Closes apache#15159
Closes apache#15209
Closes apache#15264
Closes apache#15267
Closes apache#15871
Closes apache#15861
Closes apache#16319
Closes apache#16324
Closes apache#16890

Closes apache#12398
Closes apache#12933
Closes apache#14517

## How was this patch tested?

N/A

Author: hyukjinkwon <gurwls223@gmail.com>

Closes apache#16937 from HyukjinKwon/stale-prs-close.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants