No-one doing anything similar? Cheers Gav
On Friday, 15 February 2013 12:08:37 UTC, Gavin Williams wrote: > > Morning all, > > Firstly, apologies for the length of this post, however I thought it > probably most useful to fully outline the challenge and the desired > result... > > Ok, so we're in the process of Puppetizing our Oracle/NetApp platform for > Live/DR running. > > The current manual process, upon setting up a new database, a set of > volumes are created to contain the various Oracle DB elements, and these > are then SnapMirror'd to the DR site. > This SnapMirror process requires a period of time to copy the base data > over... This time period is directly relational to the amount of data > required... I.e. a copy of 20Gb may take an hour, 200Gb may take 10 > hours... > During this period, the SnapMirror resource is in an 'initializing' state. > Once the data copy is complete, then the resource will change to an > 'initialized' state. > The next step in the process is then to break the relationship so that the > DR end can be used in a R/W mode... > > Now, in order to Puppetize this, I need to be able to replicate the above > behaviour... > I've got Puppet to create and initialize the relationship, and that works > as expected. However Puppet doesn't currently care about the relationship > state. Now that's easy enough to add in as a new property against the > type/provider. > However what I'm struggling to understand is how, or if it's even > possible, to automate the switch from 'Initialized' state to a 'Broken' > state upon completion of the initialization stage??? > > Now these databases definitions are currently driven from a YAML backend > which maintains information such as database name, volume information, > primary netapp controller, replication netapp controller, etc... Currently, > this YAML file is just a file on the puppet master... However there are > ambitions to move this into a more dynamic backend, such as CouchDB or > similar... So that opens the possibility to automatically update the YAML > resource state.. However Puppet still needs to be able to support updating > that backend based on the information it gets from the actual resource... > > So to flow it out: > > 1. Create a new database in backend -> > 2. Puppet creates volumes on primary -> > 3. Data is added to volumes -> > 4. Backend updated to indicate replication is required -> > 5. Puppet creates volumes on Secondary and adds Snapmirror > relationship -> > 6. Snapmirror initializes in background -> > 7. Puppet periodically runs against network device and checks resource > state -> > 8. Backend resource state is updated following each run? -> > 9. Snapmirror initialization completes -> > 10. Puppet runs, detects new resource state and then triggers break? > 11. Backend resource state updated to 'broken'? > > Now 1 to 7 above are fine, but 8 to 11 are where I get a bit unsure... > > So, that's the challenge... Am I barking up the wrong tree, or is this > something that Puppet could manage? > > Cheers in advance for any responses. > > Regards > Gavin > -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
