Yeah, I don’t like how the composite resource removes the individual resource-y nature of each thing. It would work but ‘all_the_true_things’, ‘all_the_false_things’, and ‘all_the_removed_things’ is unpalatable.
That is what I’m finding as well and prefetch is working, I was hoping that there were higher level hooks I was missing that would let me carry some execution across resources something like a ‘flush_provider’. I’m wondering if I can create resources dynamically for the required changes execute, update, and fall back to individual resource modification; ‘batched_slow_command’ unless that really sounds viable I’ll just shelve this as something we need to live with. I’m afraid that while it could probably be made to work it will be overly messy, confusing, and the applicability is too specific to this one case. Thanks Shawn > On Jan 28, 2016, at 1:31 PM, Luke Kanies <l...@puppetlabs.com> wrote: > > We’ve tried multiple times to build something to support this within the RAL, > but we’ve never been able to come up with something sufficiently robust. > > We do have ‘prefetch’ for combining discovery commands, but nothing for > combining the execution of the commands, AFAIK. > > > On Jan 27, 2016, at 1:03 PM, Michael Smith <michael.sm...@puppetlabs.com > <mailto:michael.sm...@puppetlabs.com>> wrote: >> >> I'm not aware of anything that supports this explicitly. If making your own >> type and provider, you could provide a parameter that takes an array of >> instances to apply and use that (kind of like the file resource has an >> overload parameter 'path'). You could then write >> >> slow_command { 'things_1_2_3_4': >> things => ['thing1', 'thing2', 'thing3', 'thing4'], >> value => true, >> } >> >> but any dependencies would have to be expressed against the namevar >> 'things_1_2_3_4'. >> >> ---- >> >> I've been part of discussions about how this would be nice for package >> providers (`yum install a b c` is faster than calling `yum install a; yum >> install b; yum install c`). However some extensions to the provider >> interface would be needed to make it happen. >> >> Conceptually providers would need a way to state they support merging >> individual declarations, some way of representing a pluralization of the >> type, and processing in the graph to merge instances of the same >> type/provider pair that don't have intermediate dependencies. >> >> Catalog ordering limits the use of this to your use case, where you declare >> several instances of the same type consecutively. It would be more >> interesting without catalog ordering, where we could merge instances of a >> type declared in different modules as long as they don't have intermediate >> dependencies. >> >> On Wed, Jan 27, 2016 at 10:50 AM, Shawn Ferry <shawn.fe...@oracle.com >> <mailto: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 >> <mailto:puppet-dev%2bunsubscr...@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 >> >> <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>. >> >> >> >> -- >> Michael Smith >> Developer, Puppet Labs >> >> -- >> 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 >> <mailto:puppet-dev+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CABy1mM%2Bkvusazxe6Wz%3DMR4NKbT%2B6Xndpw5f9U%3D0j%3D4g6nFML9Q%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/puppet-dev/CABy1mM%2Bkvusazxe6Wz%3DMR4NKbT%2B6Xndpw5f9U%3D0j%3D4g6nFML9Q%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>. > > > — > @puppetmasterd | http://about.me/lak <http://about.me/lak> | > http://puppetlabs.com/ <http://puppetlabs.com/> > > -- > 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 > <mailto:puppet-dev+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/A76EB163-0090-4E6B-8BDF-BADB6DA6B6CC%40puppetlabs.com > > <https://groups.google.com/d/msgid/puppet-dev/A76EB163-0090-4E6B-8BDF-BADB6DA6B6CC%40puppetlabs.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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/76A99F23-2F09-4AE1-A8A1-355193A2AAAA%40oracle.com. For more options, visit https://groups.google.com/d/optout.
