On Thursday, April 19, 2018 at 2:30:11 PM UTC-5, Thomas Müller wrote: > > > > Am Donnerstag, 19. April 2018 19:18:34 UTC+2 schrieb Christopher Wood: >> >> To challenge an assumption, what are you gaining from having more than >> one puppet infrastructure (puppetservers+puppetdb)? >> >> Could you perhaps handle your dev stuff with another environment or set >> of puppetservers under the same CA with the same puppetdb? >> >> Is there any reason for a separate puppet infrastructure to live longer >> than it takes to proof an upgrade for production? >> > > I can't just throw away the dev infra after preparing changes for prod > because of non-technical reasons. i'm limiting the usage of the dev system > as much as I can, but there will be system connected to this dev infra. but > I also want the data in the prod puppetdb to have a single point to make > queries/reports (third party departments) or run octocatalog-diff to run > against real facts from any system. >
That seems to respond only to Am's last question. You can have varying degrees of dev / prod separation while still maintaining a shared CA and puppetdb, and that has nothing to do with the lifetime or life cycle of the dev machines. I strongly advise at least the shared CA if you're contemplating combining dev and prod data by any mechanism. There are several good reasons to prefer the minimum separation of Puppet infrastructure, especially since for at least some purposes, you want to aggregate the dev and prod data. And doing so would take care of the problem up front -- there would be no extra step needed to aggregate dev and prod data, because it would not be physically separated in the first place. > > Another usecase could be to have a async puppetdb connection from the > second datacenter. If the connection between the datacenters is not stable > enough to use a single puppetdb I would need to add a puppetdb per DC.Then > I also would want to sync data to the central puppetdb instance. > > Is that an *actual* use case or a hypothetical one? If hypothetical, then don't let it influence your decisions about your actual use cases: if and when you need to account for that, the details will matter, and the technological landscape will have changed, so any time, effort, and compromises made to accommodate it now will probably be wasted. If it never materializes as an actual use case, then resources spent now to accommodate it will *definitely* be wasted. If you do need to account for it now, then you should still use at least a common CA. It might make sense to use common aggregated puppetdb database, too, maybe supported by database synchronization between the PG instances at the PG level. It's hard to make good recommendations, however, without a better handle on the requirements for this scenario. John -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/09201110-7ca2-4757-ae3d-56e7b3e08346%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
