Puppet users - Oct 2012 - Selectively sharing stored configuration among puppet masters?

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.

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.

Is there another option?

Thanks.

-- 
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/-/wv1253gDk8wJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.