Morning All I posted this on Puppet-users a few days ago, but I thought i'd post it on here aswell to get a Dev's view-point...
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 Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
