On Sun, Sep 1, 2013 at 9:40 AM, Dustin J. Mitchell wrote:
> It's not quite *static* content. I can see a lot of ways that this
> might be useful to users. For example, I host yum/apt/DMG repos (and
> maybe nuget too!) on my puppet masters, and as I scale puppet masters
> I will want to use shar
It's not quite *static* content. I can see a lot of ways that this
might be useful to users. For example, I host yum/apt/DMG repos (and
maybe nuget too!) on my puppet masters, and as I scale puppet masters
I will want to use shared storage for those - probably NFS. So being
able to add the stat
On Mon, Aug 26, 2013 at 10:48 AM, Dustin J. Mitchell wrote:
> The current situation is that master monitoring basically consists of
> a no-op HTTP request. We'd like to get to a point where it includes
> live status of the master. It makes sense for that live status to
> include among other thin
The current situation is that master monitoring basically consists of
a no-op HTTP request. We'd like to get to a point where it includes
live status of the master. It makes sense for that live status to
include among other things some manually-flippable "in_service?" kind
of switch.
My understa
I just read over the PR that you linked to. It looks like an interesting
idea, but I have to wonder about it a little bit. This proposal isn't to
add automated metrics to the puppet master to keep track of things like
compile stats, file request stats, etc. It is more of a manual mechanism
for the
I thought I'd kick off discussion of this ARM,
https://github.com/puppetlabs/armatures/pull/60/files
(I started discussion in the pull req, but this is probably a better
place for it)
First, the summary is about the implementation - it should probably
start with the goal: "load balancers should
