[
https://issues.apache.org/jira/browse/SLIDER-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15406276#comment-15406276
]
Billie Rinaldi commented on SLIDER-1107:
----------------------------------------
Thanks for the review, [~gsaha]! Here are some answers to your comments. I am
unit testing a patch that addresses everything I haven't mentioned below.
bq. This will result in the cmd to be something like "slider resource
--resource <>". Do you think we should name it to something like --source (or
something more appropriate)? It goes hand in hand with --destdir. What do you
think?
This command matches the keytab install command, which has slider keytab
--keytab <>. I think the idea is that you're executing a command that uploads
resources, and the --resource argument specifies which resources you're
uploading.
bq. Also, we should create a --help option (like other commands like create
has) such that ./slider resource --help provides usage details for resource
command.
All commands automatically have a --help option inherited from
AbstractActionArgs.
bq. Should we call the method fromJson?
It appears this method is unused, so I'll just remove it.
bq. Was intent here to check if (clientRoot == null && config != null) ?
No, we want the user-provided client root to override the default.
bq. Why is this method synchronized and static?
The uploadResource method needs to be synchronized so that the method never
overwrites a resource that has already been uploaded. If that happens, the AM
will throw an exception saying the resource has been modified. It's static
because it doesn't access any instance variables, plus there is only one
instance of the ProviderService in the AM. It wouldn't be a problem to remove
static, if you'd prefer that.
bq. I am not sure I understand what happens when finished is set to false and
the while loop goes over again. Can you explain?
This is iteratively substituting site property values into other site property
values. It only stops when the values stop changing (that is, it keeps going if
one of the values changed on the last pass). Previously we only allowed one
layer of substitution, so you could substitute v1 into v2 but not v1 into v2
into v3.
bq. Can these cause backward compatibility issues?
I don't think so. These changes are fixing a bug that shows up when you try to
include packages at the application level, which is allowed by our Java
structures but not by the MetainfoParser.
> Generate app configuration files in AM
> --------------------------------------
>
> Key: SLIDER-1107
> URL: https://issues.apache.org/jira/browse/SLIDER-1107
> Project: Slider
> Issue Type: Bug
> Reporter: Billie Rinaldi
> Assignee: Billie Rinaldi
> Fix For: Slider 1.0.0
>
>
> Currently, each container generates its own application configuration files.
> Instead, we could do this in the AM and have YARN localize the configuration
> files. Having some basic config generation in the AM may allow us to
> simplify the config generation code in the app packages. Also, it would be
> much better in the case of Docker containers, where we would prefer not to
> have to execute our own code inside the container.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
