Yes, you will still be able to use separate options for master vs. "everything else".
On Tue, Jun 26, 2012 at 11:12 AM, Jo Rhett <jrh...@netconsonance.com> wrote: > If I am reading this right, you are maintaining the option to keep the > master separate and that's good. I've only used a common vardir for agent > and master at one site, and it turned out to be a disaster when we had to > move it. Everywhere since I've always kept the master vardir, etcdir, etc > completely separate. I would strenuously object to anything which forced > these things to be shared. To me the master and agent functionality are > completely distinct and should remain so--or at least allow us to keep them > separate at our sites. > > On Jun 25, 2012, at 2:18 PM, Chris Price wrote: > > We've been doing some work lately to harden the pluginsync functionality > for Puppet 3.x. An issue was brought to my attention by Jeff McCune: > > In current versions of puppet, it's possible to configure things like your > vardir and libdir in any section of the config file; potentially, this > means that you can specify a different libdir for all three of ["main", > "master", "agent"]. > > This causes problems with respect to pluginsync; when you run an agent, it > will sync down plugins / modules / faces from the master into the *agent's* > libdir. Then, when you try to run a face (even the "help" face), your > libdir will be set to the "main" libdir, and thus it won't have the content > that it needs from the previous agent run. > > The basic problem here is that all of our various client-side programs > *must* share the same libdir. Thus, it seems that we need to restrict the > ability to set these for individual client programs. > > We have a short-term and a long-term solution in mind to resolve this. In > the short term, we will simply disallow libdir and related settings from > appearing in any sections of puppet.conf other than "main" and "master". > (This will still allow the master to have a separate libdir from > client-side programs.) The ticket and pull req for this are here: > > http://projects.puppetlabs.com/issues/15211 > https://github.com/puppetlabs/puppet/pull/875 > > Slightly longer term, we are thinking of simply removing support for > "run-mode"-specific configuration sections in the puppet.conf file. We > would only allow three sections: "main" (possibly renamed to "global" or > similar), "master", and "ca". (Obviously you could still specify > environments in there as well, though we probably should move those to a > separate config file in the future.) > > This is filed as a ticket here: > > http://projects.puppetlabs.com/issues/15212 > > Would love to hear any feedback that anyone has on this topic! > > Thanks > Chris > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet > projects. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-dev@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
