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 <[email protected]> wrote: > > On Feb 6, 2016, at 4:09 PM, Trevor Vaughan <[email protected]> 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 <[email protected]> > 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. > 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 [email protected]. 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.
