Hello,
On Fri, 2 Jul 2010 09:57:37 -0700 Luke Kanies <[email protected]> wrote: > On Jun 29, 2010, at 6:56 AM, Annie Rana wrote: > > > Hi all, > > > > I am new to Puppet and Ruby. Currently I am using puppet iptables > > work > > [...] > > within initialise method or even after that. It is very important > > for me to understand the flow because TC rules would also be > > incorporated with same iptables rules. > > I can't help too much on this particular code -- you're definitely > right that it doesn't follow what we consider to be recommended > practice. For instance, I can't really recommend the style of > development used in this module - it involves quite a lot of class > variables, and uses no provider. That isn't to say it's wrong per > se > - whatever works, works - but it's always going to be a bit tougher > to understand and maintain this way. Annie, as Luke politely suggests, this iptables type is definetely a bad example. Vcsrepo, sudo and other recent types are much better source of inspiration, IMHO. > However, the thing that's probably confusing you is the extent to > which the framework (mostly the transaction class) is making calls > against the resource type. It looks like everything's being driven > by the 'evaluate' and 'initialize' methods. 'initialize' is a bit > obvious, but 'evaluate' is called by the transaction. > > Note to the developers of this module - in 2.6, the 'evaluate' > method goes away, so this code won't work any more. Excellent, this gives us a deadline to fix this dreadful piece of code :-) > The transaction calls 'evaluate' on the resource, which would > normally produce a bunch of change objects, which the transaction > then applies, thus actually doing work. In this case, it's being > used as a hook to get some setup done, it looks like. One reason this type is a bit wierd is that firewall rules need to get applied in a very precise order. Puppet's before/require mechanism isn't really helpful here. Either you have resources tied together in a extremely rigid way (annoying if you put these resource in classes which don't get included on every node): iptables { "rule 1": } iptables { "rule 2": require => Iptables[rule 1] } iptables { "rule 3": require => Iptables[rule 2] } or you drop the require parameters and have them get applied in random order, which will be an issue except for extremely simplistic firewall setups. So the way puppet-iptables works is that it collects every Iptables resource in a class variable, and when there are all there, orders them based on the namevar and then feeds the formatted output to the "iptables-restore" command. This is the way it was done by the original author in october 2007 (puppet 0.23 something) and wasn't fundamentally changed since then. As I guess Annie is going to have the same sort of need for her TC type, I'm wondering what would be the "2.6-way" of achieving this use-case ? Is there a good way of holding back changes which have to get applied on a node, and only applying them after some sort of post-processing (or post-ordering) ? Or maybe is there a was to force some sort of implicit resource ordering, without the user having to resort to before/require params ? Thanks for sharing your insight ! Marc -- 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.
