Skip to content

[Spark-15155][Mesos] Optionally ignore default role resources #12933

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

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 _ => Set(Some("*"), role)
}
val acceptedRoles = roles.flatten
logDebug(s"Accepting resources from role(s): ${acceptedRoles.mkString(",")}")
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

*/
protected def getAcceptedResourceRoles(props: Map[String, String]): Set[String] = {
getAcceptedResourceRoles(
props.get("spark.mesos.ignoreDefaultRoleResources") match {
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]) = {
val roles = ignoreDefaultRoleResources match {
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?

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