On Wed, Jul 20, 2011 at 5:07 PM, Brice Figureau <[email protected]> wrote: > Hi, > > Foreword: the work I did is very basic in terms of code helping support > other devices (beside the transport stuff itself that you apparently > don't need). My point is that I believe we'll see more patterns of > similarities when adding new device types, from which we would refactor > the commonalities. > > But that's awesome to have someone else willing to add more devices :)
Yes, and it was awesome to hear the network engineers reaction to developers writing puppet manifests to manage network device configuration, specially when they saw noop of against a device, then puppet apply. > I didn't want to extend Facter with the exact same transport and device > system as I included in puppet just to return a bunch of facts. So for > the moment facts are outside of facter. Yep, makes sense. > The problem with testing the network device is that you actually need > the said device :) I'm testing against a VM at the moment. > But you can unit test the facts. In the cisco case I extracted some > textual configs of some of the device I had access to and used this to > feed the spec tests, checking the returned facts matched what I was > expected. I believe you can do the same for F5 (and by that I admit my > total ignorance of those devices). I'm still learning spec, so feeling my way on this at the moment. > Note that we might be able to extract the common architecture of facts > extraction from both the cisco and f5 implementation. One reason I > didn't even try was that it's difficult to generalize when you'll have > only one implementation. I'm pulling all the data available in systeminfo, here the reference doc: http://devcentral.f5.com/wiki/iControl.System__SystemInfo.ashx After I'm finished, I'll compare against the Cisco facts and see what can be consolidated. > That's how I first tested the system. I started doing everything in the > provider and the network_device, and was testing with puppet apply. > My pattern for testing was first to manually extract the various bits of > configs from the device, then I created the specs, implemented the > parsing, and then finally checked with puppet apply I was able to apply > configs to the target device. Ok, good to know I'm on the right track. > You can refactor this with a bit of metaprogramming: > %w{on_service_down allow_nat_state}.each do |m| > define_method(m.to_sym) do > @@bigip[@@modules].send("get_#{m}", resource[:name]).first > end > end > > It might be possible to even go further with a method_missing > implementation. Thanks for the example, it's easy to understand and very helpful. For now I'm going complete it as is and come back to the metaprogramming part since it's quire a bit of headache to troubleshoot. > I'm not sure what could be the problem :( > Could it be a case sensitivity issue of the f5.rb file? > Do you have the f5.rb file in lib/puppet/provider? > What's in the f5_pool.rb file? Yeah, I should not be writing the connectivity to F5 over and over again in each provider class. Not sure if I've done it the right way, I wrote util/networkdevice/f5.rb and used extend Puppet::Util::NetworkDevice::F5. Here's the code snippet which is working for me: http://pastie.org/2246712 > I'm usually available during CEST day time on #puppet-dev if you need > live discussion. Will do. Thanks for all the help! Nan -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
