> 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
> <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-iptables>
> https://github.com/simp/pupmod-simp-cgroups
> <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]
> <mailto:[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]
> <mailto:puppet-dev%[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
>
> <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
> <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]
> <mailto:[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
> <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.
For more options, visit https://groups.google.com/d/optout.
