On Tue, Feb 24, 2015 at 10:31 AM, Wil Cooley <wcoo...@nakedape.cc> wrote:
> On Mon, Feb 23, 2015 at 2:17 PM, Jeff McCune <j...@puppetlabs.com> wrote: > >> On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan <tvaug...@onyxpoint.com> >> wrote: >> >>> Yes please. Moving this out of $vardir/ssl will be quite irritating to >>> teach existing users about the new product usage. >>> >> >> Even if we kept it in $vardir/ssl, this would mean the path is >> /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please >> note the agent and master vardir's in the specification). Is your concern >> that SSL data remain in $vardir/ssl or that they remain in >> /var/lib/puppet/ssl ? >> > > > It does not seem like a great idea to put $vardir under /opt. /opt is only > sometimes a separate file system from / and could grow much more variably. > If anything, I'd rather see the some of the directories under $vardir to be > moved to /var/cache/puppet, depending on whether the data is transitory or > persistent. (Much of it, in fact, I would expect to be cache, but > 'reports', 'bucket' and possibly 'clientbucket' stand out as non-transitory > so kept in 'lib'; if ssl were not in /etc I would expect it to be in 'lib' > as it is not transitory.) > /var is sometimes only a separate filesystem not as well. We plan to keep (as we have for PE) the SSL stuff in /etc/puppetlabs/puppet/ssl. Putting it in cache doesn't make a ton of sense, at least in my head a cache should be able to regenerated upon deletion. That wouldn't work well for ssl certs. Distros place ssl certs as configuration information in /etc- however since distros can't ever seem to agree on where that stuff should go, we're putting it with our application stack. > I agree with the hating on '/etc/opt' and '/var/opt' too. > I hate those so much. > > Also, if hiera, c?facter and mco are going to be installed in > /opt/puppetlabs/puppet, why bother with the extra directory level and then > have to bother symlinking into /opt/puppetlabs/bin? I'm guessing that there > is an expectation that other projects/products will go alongside the > 'puppet' level, but then it seems weird to put hiera c?facter and mco into > 'puppet' instead of their own directories. I guess you're putting ruby into > the 'puppet' directory, so that's why... Hrm > There will be other directories at the puppet level in some types of installations. You could see puppet-server being there, or puppetdb or something. More information on that to come in the future. > > Blue. I say it should be blue! > > Wil > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMto7LJ0yXnzk9HDBz4hhoXM%2BLi%2B27ue0XqcEixrAOzVouiRZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
