Ugh, I forgot about that. I fixed it over in IPTables but may not have gone back to cgroups since it was pretty much deprecated under systemd in EL7.
Try this one: https://github.com/simp/pupmod-simp-iptables/blob/master/lib/puppet/provider/iptables_rule/manage.rb . Basically, nailing up the fact that these are globals. I think that I figured out how to do these actually correctly but I haven't had time to test it. Trevor On Wed, Mar 2, 2016 at 3:31 PM, Shawn Ferry <shawn.fe...@oracle.com> wrote: > > On Feb 6, 2016, at 4:09 PM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > > Hi Shawn, > > This is very much possible, but the implementation is going to be a true > hack that pollutes the global namespace until > https://tickets.puppetlabs.com/browse/PUP-4002 is fixed. > > > Thank you for the examples. > > The nature of the work is different so I don’t see how to use the num_runs > == num_resources approach to determine when to actually apply the changes. > Instead I ended up using self.post_resource_eval which I think is > sub-optimal. Is there some other method that I’m missing which is called at > the end of each resource even if it doesn’t change? > > I’m seeing two different approaches: > $iptables_rule_classvars = { > @@cgroup_rule_classvars = { > > @@classvar doesn’t work for me without going through the class itself > otherwise I get 'class variable access from toplevel’ warnings and later > 'uninitialized class variable' errors. > e.g. Puppet::Type::Pkg_facet::ProviderPkg_facet.send(:class_variable_set > works, while self.send(:class_variable_set gets undefined method > `class_variable_get’ > > I can remove_class_variable when I’m done and also not pollute the global > namespace this way. I don’t really like needing to use the full class name > instead of self.send but I’m not seeing why it fails otherwise. > > > Thanks > Shawn > > ruby 2.1.6p336 (2015-04-13 revision 50298) [amd64-solaris2.12] > Puppet v3.6.2 > > > Ideally, it would be something that is GC'd with the catalog, but we'll > see where things go. > > I've done this both for IPTables and CGroups in the following modules > mainly because any error in the application of their chain would be a > disaster so we wanted to wait until we could check everything and apply > them seamlessly to the system. > > https://github.com/simp/pupmod-simp-iptables > https://github.com/simp/pupmod-simp-cgroups > > The CGroups example is going to be MUCH easier to follow. > > Essentially, I create a class variable that compiles the end result and > then executes it on the last resource in the catalog. The last resource in > the catalog is detected by counting what resource you're on against the > total number of that resource type in the catalog. > > The main downside to this (besides the global namespace nastiness) is that > you only see the last resource in the catalog change in your report. Not > ideal, but certainly functional. > > Make sure that you undef the class parameter at the end of your > application so that you don't end up with memory leaks. > > Trevor > > On Wed, Jan 27, 2016 at 1:50 PM, Shawn Ferry <shawn.fe...@oracle.com> > wrote: > >> I have a command that takes one or more effectively free form arguments >> and executes somewhat slowly and sometimes if things are changing much more >> slowly. Lets say 30s nominal execution in the simple case. >> >> I’m not finding a list of hooks to see if anything is appropriate. Flush >> would be great if I was processing a bunch of individual arguments for a >> resource but I need something that allows me to defer these updates until >> the end of processing for a provider and flush them together. >> >> Am I missing an alternate method to do something like this or the correct >> place in the docs? >> >> >> Thanks >> Shawn >> >> >> If I have something like the following it takes at least 2 minutes >> >> slow_command { [‘thing1’, 'thing2', ‘thing3’, ’thing4']: >> value => true >> } >> >> /tmp/slow_command thing1=true >> /tmp/slow_command thing2=true >> /tmp/slow_command thing3=true >> /tmp/slow_command thing4=true >> >> If I manually invoke or exec it it takes 30s >> >> /tmp/slow_command thing1=true thing2=true thing3=true thing4=true >> >> >> :::slow_command::: >> #!/bin/sh >> sleep 30 >> echo $* >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/9D1DB354-8D30-448E-A461-54C67D4B8B26%40oracle.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > > -- This account not approved for unencrypted proprietary information -- > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXa%2BDS3O4UP3PkBCYHwe385hSbemc122akg1JYRFpL2zw%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXa%2BDS3O4UP3PkBCYHwe385hSbemc122akg1JYRFpL2zw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/0FA400CD-1B06-4B4E-A751-5504F67197A0%40oracle.com > <https://groups.google.com/d/msgid/puppet-dev/0FA400CD-1B06-4B4E-A751-5504F67197A0%40oracle.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWpbLVx8w8a8FvLcRvcorz89itb_iLhmOPaGx0pXYJ_hw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
