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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
