This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 472823 - multiple use-case configurations needed for Puppet
multiple use-case configurations needed for Puppet
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: puppet (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-24 16:08 EST by Matthew Farrellee
Modified: 2010-02-19 03:37 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-19 03:37:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Farrellee 2008-11-24 16:08:47 EST
Need a standard, supportable way to specify default, product specific Puppet configurations
Comment 1 Hugh Brock 2009-05-22 11:09:57 EDT
Hmm Matt I know we've talked about this but I'm still not sure what you mean. Is this an oVirt bug?
Comment 2 Matthew Farrellee 2009-05-26 09:39:58 EDT
This is painfully old, but probably still relevant. It was about having a means to install the puppet package and then some configuration package without having to modify files from the puppet package (modification believed to result in hilarity).
Comment 3 Joey Boggs 2009-05-26 10:22:15 EDT
Is the appliance a definition of this?  Only problem is that we rely on very specific information from the user and live system for ip addresses/interfaces/passwords/etc. We can reply on facter to grab the ip's for us, defaults for passwords, but I don't think we could build enough reliable scenarios due to so many possibilities in configurations. Have you ran though the latest version of the installer, it works worlds better than it did back in November.
Comment 4 Matthew Farrellee 2009-05-26 10:28:49 EDT
This is a configuration issue of the puppetd itself on managed nodes, e.g. tell it to talk to foo.bar.com instead of puppet.bar.com or necessary changes to puppet.conf, namespaceauth.conf and site.pp.
Comment 5 Bryan Kearney 2009-05-26 11:00:00 EDT
If I recall, this came out of the need for one project to have a default configuration for puppet which is different from others. We debated if the config should go into the base package, and decided against it. This is really no different then one project needing a unique setting in the apache.config file. You either manage this via documentation (e.g. manual), a config RPM, a kickstart post section, or an installer.
Comment 6 Matthew Farrellee 2009-05-26 11:11:54 EDT
IIRC, there were things that could be done to allow importing of some configuration without modifying the puppet package owned configuration files (e.g. generalized site.pp or puppet.conf), and some configuration needed external intervention (e.g. foo.bar.com). The former is more of a focus here. In an apache or yum world it might be implemented as a conf.d directory.
Comment 7 Matthew Farrellee 2010-02-18 22:30:13 EST
This can be closed. We are moving away from puppet in MRG.

Note You need to log in before you can comment on or make changes to this bug.