On Tuesday, January 15, 2013 4:34:19 AM UTC-6, Gavin Williams wrote: > > Morning all... > > Firstly, apologies for the length of this post, however I thought it would > be beneficial to fully explain what I'm trying to achieve. > > I've started using Hiera with Puppet 3.0, and must say I'm very impressed > soo far. It's handled the bulk of what I've thrown at it so far without any > issues... > > However I'm now starting to think about some of the more complex > challenges we're hoping to solve with Puppet... > One of those is Oracle Database configuration management... > > Under this falls the following components: > > - NetApp Filer volume configuration - Active site and DR site, with > SnapMirror relationship between the 2. > - Oracle Database server configuration - Active site and DR site. > > As you can see, that's effectively 4 separate components, spread across 2 > separate sites, but which are closely related... > > Currently, all our Hiera configuration is driven from the physical view, > that is a host, or an environment, or a data-centre... > However I'd like to try and turn this configuration on it's head and go > logical... That is each Database instance has it's own configuration data, > which contains all the relevant information such as what it's Active and DR > NetApp filer is, what it's volume sizes are, what Active database server it > should live on, where it should be in DR mode... > > Now this all seems quite easy to define in Hiera Yaml... Something like > the following should cover it: > --- > database_sid: 'ORACLE01' > active_filer: 'site1-nactl01' > replica_filer: 'site2-nactl01' > active_database_server: 'site1-db01' > replicate_database_server: 'site2-db01' > oracle_version: '11.2.0.3' > volumes: > ORACLE01_oractrl: > ensure: present > size: '1g' > ORACLE01_oradata: > ensure: present > size: '150g' > ORACLE01_oraredo: > ensure: present > size: '10g' > ORACLE01_oratemp: > ensure: present > size: '10g' > ORACLE01_oraarch: > ensure: present > size: '20g' > snapschedule: > minutes: 0 > hours: 36 > days: 0 > weeks: 0 > snapmirror: > ... > > However the challenge I'm currently struggling to get my head around is > how I can turn that logical view into the various physical views that are > needed for each component... > It also gets further complicated in that there is going to be multiple > database instances, with some commonality between them, and some > variation... > > So if I'm running puppet on *site1-db01*, I want to process all databases > that have either an '*active_database_server*' or a '* > replicate_database_server*' value matching the hostname. > If running puppet against *site1-nactl01*, then need to process all > databases that have an '*active_filer*' matching the hostname... > > Any ideas on where I could begin? > Or is there a better way for me to achieve this? >
Arranging for each node to draw on (only) the correct data is normally a question of how you structure your data and organize your hierarchy. Hiera has no built-in mechanism for applying the kind of selection predicates you describe, so you would layout your data such that nodes only get the data for the instances that should be configured on them. Failing (or instead of) that, you can enhance selectivity by declaring all the relevant resources virtually, and then using collections with appropriate predicates to realize only the ones that are wanted for the current target. If that's insufficient then you could consider creating custom functions to sift the wanted data from the available data. You might even be able to make it generic enough to be reusable. 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/-/8fYMI6vvWUIJ. 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.
