On Jul 5, 2010, at 8:25 AM, Marc Fournier wrote:
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 ?
The short answer is that there's nothing built into the framework that
will do this, so you have to do something like what is there.
However, there are better and worse ways of forcing something like
this, and my guess is that we could find better ways.
In particular, you could (as a not-completely-thought-out example) use
'prefetch' on the provider to set up relationships. Normally
'prefetch' is just used to collect the current state of the system,
but it can actually modify resources, although it wouldn't normally.
You could set the order you need as relationships on the resources
there.
Otherwise, stick with the same model but clean it up a bit, although I
apparently don't have any great ideas for how to do so. :/
--
What's the good of having mastery over cosmic balance and knowing the
secrets of fate if you can't blow something up?
-- Terry Pratchett, "Reaper Man"
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
