On Thursday, October 11, 2012 6:46:44 PM UTC-5, Amos Shapira wrote: > > Hello, > > We've just split off using another groups' puppet master and started using > our own master. > > One thing this limits us with is that we want them to start backing up a > couple of our servers using their Bacula server. > Their Bacula server is configured using Stored Configuration from their > puppet master, but now that our systems configure from our puppet master, > their configuration isn't known to their bacula server. > > The only way I can think of to achieve that without requiring a change in > Puppet is to configure our puppet master to use the other teams' stored > config db: > Pros: no extra work > Cons: depends on them agreeing to that (they don't). Means that we share > all our stored config with them and vice verse. >
Additional cons: fundamentally broken It's just plain wrong to inject stored configuration data into a foreign environment. From the other side, I would rate it extremely unwise to accept foreign SC data, too. You need to provide the data by some other mechanism. When you say the other group uses stored configuration for the job, I presume you mean more specifically that they are relying on managed hosts to export resources intended to be collected on the Bacula server. To integrate as cleanly as possible into such a system, you need to provide data to them in a form that is easy to convert into resources. There are several alternatives, with some of the more likely being: - Provide an actual Puppet manifest defining a class they can add to their Bacula server. - Provide a hash in YAML or some other form that they can load into Puppet and feed to the create_resources() function. I name YAML specifically because that could tie in nicely with hiera if they are using it. You will need to arrange some kind of mechanism by which to synchronize that configuration file, whatever form it takes, with the other group -- perhaps via a network-accessible filesystem or a periodic pull from a source-control repository. > > Otherwise, how about one of the following new features: > > 1. Allow a puppet master to define multiple stored config db's and let > resources specify which of the db's they need to be pushed to. > 2. Allow a puppet virtual resource to specify to be read multiple > stored config db's. > > No. The problem is not so much control of the DB, but rather its content. I would no more accept stored configuration data from a supplemental database populated from a foreign environment than I would accept the same data directly into my SC database. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/_8pTvWdrsz4J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
