Just to add on things that I'd like to see:

Tuning
- When it's not CPU, it's RAM. What to do when you have massive catalogs
(maybe not an issue?).

Operating
- Proper log rotation and maintenance

Security
- What do I need to let through?
- What do I need to lock down?
- How do I easily split off my CA from my Master?
- What to do in locations that don't allow JMX (how to disable it)
- What this setting set does:
  certificate-authority: {
    certificate-status: {
        client-whitelist: []
    }
  }

Right now, these are just things that I need to figure out when I have
time. If someone knows the answers, that would make things much easier.

Thanks,

Trevor

On Mon, Sep 29, 2014 at 4:53 PM, Ramin K <[email protected]> wrote:

> On 9/29/14 2:09 AM, Ken Barber wrote:
>
>>
>>           The information around tuning Passenger/Puppet explicitly
>>> provided
>>> by Puppet Labs was mostly crap.
>>>
>>
>> Indeed, it was a bit of a black art because of this. It wasn't until
>> later that Passenger even added the ability to reasonably introspect
>> what was going on in Passenger.
>>
>>  It would be extremely useful for everyone if
>>> there were 4-8 pages of serious and indepth docs specifically about
>>> running
>>> puppet_server on the JVM. If that doesn't happen, you'll be fighting the
>>> supposed poor performance of every un-tuned puppet_server installation
>>> for
>>> years.
>>>
>>
>> Sounds like something ticket-worthy to mention. We already have some
>> of this for PuppetDB, a lot of it is similar for this platform as
>> well. I'm pretty sure this will become a hot topic, so I doubt it will
>> be left alone. I expect the new puppet-server to incur more traffic
>> than PuppetDB for example, so they'll probably see issues we have not.
>>
>
> I can take a shot at it. Where's the best place to put it? Or if you want
> to file it, I'll update it. My list at the moment looks like following if
> anyone else wants to chime in.
>
> Tuning
> - puppet_server specific tuning for JVM 7/8/whatever.
> - Call out the top five terrible "go fast options" that are commonly found
> in blog posts.
> - Discussion of puppet_server bottlenecks. CPU. It's always CPU.
>
> Operating
> - The effects of of restarting, hard and graceful
> - Discussion/support of log levels, where to log, etc.
> - Haproxy in front, ssl termination, and other HA or throughput enhancing
> techniques.
>
> Monitoring
>   - status routes (is the puppet_server up and mostly working)
>   - dependency routes (can puppet_server hit puppet_db, etc)
>
> Statistics
>  - some explanation of jmx
>  - interesting keys. I'm not familiar, but I imagine it's like a MIB. "We
> have an snmp MIB." "Great which keys are the ones we should definitely
> monitor?" "No idea." "Okay if I create a new load balancer where does that
> show up?" "No idea."
>
> Ramin
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" 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-users/5429C6B8.2040106%40badapple.net.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" 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-users/CANs%2BFoX_NW6v1Utsi2e4SufLehFNHUzCY5YTfj5WDOiXZc4%3D-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to