On Tue, Feb 24, 2015 at 10:31 AM, Wil Cooley <[email protected]> wrote:

> On Mon, Feb 23, 2015 at 2:17 PM, Jeff McCune <[email protected]> wrote:
>
>> On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan <[email protected]>
>> 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 [email protected].
> 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 [email protected].
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.

Reply via email to