On May 22, 7:24 pm, Sean Millichamp <[email protected]> wrote: > On Mon, 2012-05-21 at 15:39 -0600, Deepak Giridharagopal wrote: > > 1) The data stored in PuppetDB is entirely driven by puppetmasters > > compiling catalogs for agents. If your entire database exploded and > > lost all data, everything will be 100% repopulated within around > > $runinterval minutes. > > I think that this is a somewhat dangerous line of thinking. Please > correct me if my understanding of storedconfigs are wrong, but if I am > managing a resource with resources { 'type': purge => true } (or a > purged directory populated file resources) and any subset of those > resources are exported resources then, if my "entire database exploded", > would I not have Puppet purging resources that haven't repopulated > during this repopulation time? They would obviously be replaced, but if > those were critical resources (think exported Nagios configs, /etc/hosts > entries, or the like) then this could be a really big problem.
That understanding of storeconfigs looks right, but I think the criticism is misplaced. It is not Deepak's line of thinking that is dangerous, but rather the posited strategy of purging (un)collected resources. Indeed, I rate resource purging as a bit dangerous *any* way you do it. Moreover, the consequences of a storeconfig DB blowing up are roughly the same regardless of the DBMS managing it or the middleware between it an the Puppetmaster. I don't see how the existence of that scenario makes PuppetDB any better or worse. > To me storedconfigs are one of the killer features in Puppet. We are > using them for a handful of critical things and I plan to only expand > their use. I'm glad that Puppet Labs is focusing some attention on them, > but this attitude of we can wait out a repopulation has me worried. If you cannot afford to wait out a repopulation of some resource, then you probably should not risk purging its resource type. If you do not purge, then a storeconfig implosion just leaves your resources unmanaged. If you choose to purge anyway then you need to understand that you thereby assume some risk in exchange for convenience; mitigating that risk probably requires additional effort elsewhere (e.g. DB replication and failover, backup data center, ...). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
