Github user devaraj-kavali commented on the issue:
https://github.com/apache/spark/pull/12753
I will update this PR with the ConfigReader and reopen the jira.
---
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
Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/12753
If you're willing to work on it you can re-open the bug. Otherwise you
should close this PR.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user devaraj-kavali commented on the issue:
https://github.com/apache/spark/pull/12753
@vanzin, SPARK-3767 was resolved as 'Won't Fix' by @srowen. I was in
assumption that SPARK-16671 covers this as well.
---
If your project is set up for it, you can reply to this email and
Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/12753
Hi @devaraj-kavali, are you still interested in updating this PR? I really
think it should use the features I added in SPARK-16671 (especially the
`ConfigReader` code), to avoid yet another way of
Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/12753
Also the PR title is misleading, since this change is adding a single
"wildcard" to a single configuration. The title makes it sound like it's way
more generic than it is.
---
If your project is
Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/12753
Hmmm... wouldn't this be a one line change (for standalone and mesos) if
instead you modified `CommandUtils.buildLocalCommand` to apply variable
substitution to `command.javaOpts` instead of just to
Github user devaraj-kavali commented on the issue:
https://github.com/apache/spark/pull/12753
@vanzin Thanks for looking into this, I have resolved the conflicts.
---
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
Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/12753
Sorry this has been forgotten for so long. I think instead of adding a new
way of referencing variables, it might be better to use the new code I'm adding
in #14468; that way it would be easier to
