> The one issue I see with that approach is what happens when your monitoring > system, *choke* nagios *choke* is dependant on said exported resources. > Wiping the database clean isn't really an option in that case or you'd need > to temporarily disable reloading your monitoring until everyone's checked > back in again. The same problems would occur if people were using those > exported resources to configure things like HAProxy, Apache BalanceMembers > or nginx upstream entities (to name a few).
This is the world I see, it won't affect everyone though and theoretically with 1 hour check-ins it will be solved next run. My fear is more around those that don't run puppet as often. > I'm not entirely getting the resource collection collision thing, what's > going on there? So because there was no environment awareness, all resources from all environments would be sent to PuppetDB with no environment being marked. As a consequence, no matter what environment you were collecting from all resources on that PuppetDB instance were thus up for collection. Without work-arounds (like what Spencer mentioned) you may potentially collect both test and prod resources (for example) that represented the same Type/Title combination thus creating a duplicate resource. The idea, is to make this all transparent and work like the old days of storeconfigs, and force collection to only be on the environment you are running in. Thus removing the need for a work around. Possibly too much 'thus' in that explanation, let me know if it makes sense. ken. -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE4bNTmwFB22YXUcZ9RcNA0ttjtWeVS9XGiE58fgSukptpO1fg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
