Hmm Matt I know we've talked about this but I'm still not sure what you mean. Is this an oVirt bug?

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).

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.

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.

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.

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.

This can be closed. We are moving away from puppet in MRG.