You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Patrick Taylor Ramsey (Updated) (JIRA)" <ji...@apache.org> on 2011/12/20 02:15:31 UTC
[jira] [Updated] (BIGTOP-313) Move puppet configuration out of
manifest and into extlookup() CSV
[ https://issues.apache.org/jira/browse/BIGTOP-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Taylor Ramsey updated BIGTOP-313:
-----------------------------------------
Description:
Previously, bigtop-deploy puppet could only be configured by editing puppet manifests, or through a small number of environment variables that set facter facts. I've rewritten cluster.pp to use extlookup to read most configuration options from a site-specific CSV file with sane defaults for most options (only hadoop_head_node and bigtop_yumrepo_uri are required to be set). These changes should make it easier to automate deploying multiple clusters with different configurations from the same manifests.
As written, the CSV files must live in $confdir/config/, where $confdir is the puppet config directory. This means that if you are manually calling 'puppet agent' on these manifests (rather than serving them from a puppet master), you are now required to specify --confdir in addition to --modulepath.
At some point in the future, may be worth moving to hiera, as yaml is a lot prettier and more flexible than CSV. I did this using extlookup so as not to introduce external dependencies (since extlookup is now in puppet core).
was:
Previously, bigtop-deploy puppet could only be configured by editing puppet manifests, or through a small number of environment variables that set facter facts. I've rewritten cluster.pp to use extlookup to read configuration from a site-specific CSV file with sane defaults for most options (only hadoop_head_node and bigtop_yumrepo_uri are required to be set). These changes should make it easier to automate deploying multiple clusters with different configurations from the same manifests.
As written, the CSV files must live in $confdir/config/, where $confdir is the puppet config directory. This means that if you are manually calling 'puppet agent' on these manifests (rather than serving them from a puppet master), you are now required to specify --confdir in addition to --modulepath.
At some point in the future, may be worth moving to hiera, as yaml is a lot prettier and more flexible than CSV. I did this using extlookup so as not to introduce external dependencies (since extlookup is now in puppet core).
> Move puppet configuration out of manifest and into extlookup() CSV
> ------------------------------------------------------------------
>
> Key: BIGTOP-313
> URL: https://issues.apache.org/jira/browse/BIGTOP-313
> Project: Bigtop
> Issue Type: Improvement
> Components: Deployment
> Reporter: Patrick Taylor Ramsey
> Priority: Minor
> Labels: deploy, deployment, puppet
>
> Previously, bigtop-deploy puppet could only be configured by editing puppet manifests, or through a small number of environment variables that set facter facts. I've rewritten cluster.pp to use extlookup to read most configuration options from a site-specific CSV file with sane defaults for most options (only hadoop_head_node and bigtop_yumrepo_uri are required to be set). These changes should make it easier to automate deploying multiple clusters with different configurations from the same manifests.
> As written, the CSV files must live in $confdir/config/, where $confdir is the puppet config directory. This means that if you are manually calling 'puppet agent' on these manifests (rather than serving them from a puppet master), you are now required to specify --confdir in addition to --modulepath.
> At some point in the future, may be worth moving to hiera, as yaml is a lot prettier and more flexible than CSV. I did this using extlookup so as not to introduce external dependencies (since extlookup is now in puppet core).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira