[
https://issues.apache.org/jira/browse/BIGTOP-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724232#comment-13724232
]
Sean Mackrory edited comment on BIGTOP-1037 at 7/30/13 6:40 PM:
----------------------------------------------------------------
In this patch, the environment variable DEFAULTS_DIR can be used to specify a
directory containing the files to source (it will default to /etc/default, as
it should). It can also be set to the empty string to disable the sourcing of
these files by the wrapper scripts and rely on the existing environment
entirely.
I've also taken the liberty of standardizing all sourcing to using the -r check
to validate the existence and readability of the files first. In my opinion,
it's hands-down the best approach we've taken, and this is just standardizing
on that check. I also corrected a few scripts that were using #!/bin/sh to
specify the bash shell. No specific reason to in these cases - just a good
chance to make sure these scripts are being consistent about the shells.
My opinion on the ideal behavior is above, but I should say that I'm not
married to the coding style used here. I'd like to be succinct, since this
shouldn't be the "default" use case, and I would like to have avoided syntax
like the [ -n ... -a ...] && lines. I struggled to find a solution that
resulted in identical behavior, was easier to read, and was relatively brief.
If you have suggestions, please do share because I think that's one thing that
could be improved.
edit: I've tested a couple of scripts thoroughly and inspected the output of
the init.d.tmpl template to make sure it's all consistent - unless someone
disagrees, I considered that plus a thorough inspection for consistency to be
sufficient testing for this.
was (Author: mackrorysd):
In this patch, the environment variable DEFAULTS_DIR can be used to specify
a directory containing the files to source (it will default to /etc/default, as
it should). It can also be set to the empty string to disable the sourcing of
these files by the wrapper scripts and rely on the existing environment
entirely.
I've also taken the liberty of standardizing all sourcing to using the -r check
to validate the existence and readability of the files first. In my opinion,
it's hands-down the best approach we've taken, and this is just standardizing
on that check. I also corrected a few scripts that were using #!/bin/sh to
specify the bash shell. No specific reason to in these cases - just a good
chance to make sure these scripts are being consistent about the shells.
My opinion on the ideal behavior is above, but I should say that I'm not
married to the coding style used here. I'd like to be succinct, since this
shouldn't be the "default" use case, and I would like to have avoided syntax
like the [ -n ... -a ...] && lines. I struggled to find a solution that
resulted in identical behavior, was easier to read, and was relatively brief.
If you have suggestions, please do share because I think that's one thing that
could be improved.
> Provide a mechanism to control the sourcing of defaults files
> -------------------------------------------------------------
>
> Key: BIGTOP-1037
> URL: https://issues.apache.org/jira/browse/BIGTOP-1037
> Project: Bigtop
> Issue Type: Bug
> Reporter: Sean Mackrory
> Assignee: Sean Mackrory
> Attachments:
> 0001-BIGTOP-1037.-Provide-a-mechanism-to-control-the-sour.patch
>
>
> Ideally, defaults files should only contain name / value pairs (as per Debian
> packaging policy), which makes it difficult for a cluster management system
> that may be managing Hadoop to control the environment when these files are
> sources and variables are perhaps exported into the environment
> unconditionally.
> In keeping with Bigtop's goal if integrating Hadoop with the underlying
> operating system, the default behavior should not change *at all*, but it
> would provide greater flexibility if there was a mechanism to disable the
> sourcing of files so that if a system wants the environment variables to be
> used exclusively, the defaults files won't override that behavior.
> Obviously since this may be a more rare use case right now, the solution
> should also be as safe and non-disruptive as possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
