[prev in list] [next in list] [prev in thread] [next in thread] 

List:       puppet-dev
Subject:    [Puppet-dev] Integrating Puppetshow with core
From:       mpalmer () hezmatt ! org (Matthew Palmer)
Date:       2006-07-31 21:46:15
Message-ID: 20060731214615.GL26240 () hezmatt ! org
[Download RAW message or body]

On Mon, Jul 31, 2006 at 10:11:52AM -0500, Luke Kanies wrote:
> On Jul 30, 2006, at 11:37 PM, Matt Palmer wrote:
> >> Are you actually using that database right now?  Is anyone?
> >
> > I'm currently using the hosts table to determine (a) which hosts we  
> > have
> > under management, and (b) the facts associated with them, but I  
> > expect that
> > I'll be fiddling with the export/collect portion of that database  
> > before
> > this project is through.
> 
> Very nice.  I didn't think anyone else was using this.

Probably nobody else was.  It's a testament to your design skills that you
happened to produce something that fit my needs exactly, before even *I*
knew I needed it. <grin>

> I assume you're using the Sqlite backend; I haven't tried it yet with  
> anything else, but it seemed painfully slow over sqlite.  Have you  
> experienced the same thing?

SQLite isn't known for it's blazing speed, but then I'm not exactly
straining it's capabilities just yet.  We'll see how it goes once it heads
into production -- at the moment I'm really only using it in test mode in my
tree, whilst haxxoring.

> >> and has very different functionality and will continue to.
> >
> > We're blurring the lines between units of functionality all the time.
> > Putting an embedded Rails app into the puppetmaster is likely to  
> > have all
> > sorts of cool effects -- the first one that comes to my mind is as a
> > reporting server.
> 
> Yeah, Puppet is desperately needing a reporting server.

I haven't looked at the reporting stuff, so I don't know where you're
storing the report data on the server, but it seems like a natural fit to
extend Puppetshow to extract, format, and display the action report data.  I
wouldn't be too surprised if the next feature request from the client I'm
currently doing this work for is something along those lines.

> >> It would be a good idea to start distributing it, though.
> >
> > Distribution will occur.
> 
> You've got packages all whipped up, or what?

I've got a bzr tree I'm working in; I'll push that out probably sometime
today -- it's pretty nominal at the moment, but it's got the bare-basics. 
Unless some disaster befalls the client, I should be spending most of today
making it far more informative, so by this arvo it should be pretty ready to
go.

> I'm assuming there still aren't "standards" on where to put Rails  
> applications -- the code would clearly go with the rest of the Puppet  
> code, but the views and controllers... I dunno.

That's one of the things I've got to work out before it can be integrated
into Puppet proper.  I'm assuming I'll work it all out...

> > At the moment, I'm only doing "look at facts", and it might lead on  
> > to "look
> > at objects".  That's quite enough to be going on with at the moment  
> > -- if
> > you want to write a fact that dumps /etc/shadow, be it on your head...
> 
> But for those sites that allow the server to contact the client, this  
> will be a concern.  If I started up Puppetshow on my network right  
> now and allowed it to contact my clients, I could see the contents of  
> any file.

Oh my.  I didn't realise it was so kimono-opening...

> For those who are just using the host and facts db, then yeah, no  
> problem.

I think I'll stick to that mode for the moment.  But you need to take
explicit action on the Puppet clients to open that hole, right?  That
Puppetshow can ask doesn't mean that the client will necessarily answer?

- Matt

[prev in list] [next in list] [prev in thread] [next in thread]