[
https://issues.apache.org/jira/browse/BIGTOP-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367053#comment-14367053
]
Michael Weiser commented on BIGTOP-1689:
----------------------------------------
I do agree that having option duplicates in the same file is not a good idea.
As an alternative to overriding, merging and reformatting of options I could
think of a samba-testparm-like program to be run after the configuration file
is created (with additional user-supplied options) to make sure that it
conforms to constraints such as each option being set only once.
Even better: Since upstream is a sister project, we should simply request
clarification on duplicate option support and possibly have the configuration
parser changed to fail on duplicate options.
I do not fully agree on the rationale for allowing overrides:
- adding the option to (partially) override what the configuration logic
generates is just as liable to create confusion on the user's and the
supporters' part as having duplicates in the config file
- the current configuration logic provides additional value over just a
dictionary of options and values such as implicitly enforcing consistency
between values by generating them from the same source value. If this logic is
not flexible enough to support typical use-cases, it should be enhanced or
simplified as required. Having the option to override will cause users to
implement complex and error-prone override configurations instead of reporting
their possibly very minor need of a logic change (and perhaps even implement it
themselves).
- if the logic isn't properly documented, it should be documented better
instead of allowing to circumvent it
- if it is too complex it should be changed to be easier to understand
- as said in a previous comment, the possibly non-obvious mapping of bigtop
hiera setting names to configuration option names (at the moment it's 95%
config option name with dots replaced by underscores in hiera) could mostly be
handled in a second step by moving explicit class parameters into a default
additional options hash. Selectively overriding the default hash could be done
using an explicit hiera_hash() merge lookup.
All in all I'd still recommend using a KISS approach and just add additional
values at the end of the config from a hash and rely on the software's
configuration file parser, an checker script or even custom parser function for
constraint validation. This would IMO suffice for 95-98% of use-cases.
However, if the consent is to go with the proposed patch, I'll be happy to test
it and give technical feedback.
> puppet: Allow merging arbitrary site configuration
> --------------------------------------------------
>
> Key: BIGTOP-1689
> URL: https://issues.apache.org/jira/browse/BIGTOP-1689
> Project: Bigtop
> Issue Type: Improvement
> Components: deployment
> Affects Versions: 0.8.0
> Reporter: Peter Slawski
> Assignee: Peter Slawski
> Fix For: 0.9.0
>
> Attachments: BIGTOP-1689.1.patch
>
>
> Puppet should be flexible in allowing arbitrary configuration name value
> pairs to be merged into a given site.xml file that was generated from a
> template.
> For example, the following could be included in site.yaml which would add a
> configuration entry for hadoop.tmp.dir in core-site.xml:
> {code}
> hadoop::common_hdfs::hadoop_core_site_overrides:
> "hadoop.tmp.dir": "/mnt/var/lib/hadoop/tmp"
> {code}
> This could be implemented as a puppet custom-function taking in the output of
> template:
> {code}
> file {
> "/etc/hadoop/conf/core-site.xml":
> content => merge_site(template('hadoop/core-site.xml'),
> $hadoop_core_site_overrides)
> require => [Package["hadoop"]],
> }
> {code}
> Perhaps another approach would be to have site.xml templates be created from
> a single map of name value pairs. The merge would happen before the file
> content is generated from the template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
