I've posted a walkthrough at https://www.onyxpoint.com/2013/07/20/storing-puppet-provider-metadata-for-single-instance-application/ if you're interested.
Comments/critiques welcome. Also, if there's an easier way to do this, that would be good too. Thanks! Trevor On Tue, Jul 16, 2013 at 7:32 AM, Trevor Vaughan <[email protected]>wrote: > It's a massive hack but seems to work. > > 1) Add a *unique* class variable hash to your provider. Class variables > are shared across *all* providers so be careful. Something like > @@classname_classvars. > 2) Add a counter on a property and an element for 'initialized' > 3) Perform whatever initialization that you need to do in the 'initialize' > define but set 'initialized' to true and never do this block again. > 4) In your chosen counting property: > 4a) Parse the catalog for all resources of that type with whatever unique > attribute that you want to select on. If you don't have multiple unique > attributes, just select everything of that type. (Only do this once because > it shouldn't change) > 4b) If you end up with the exact same number of runs as you do resources > then just return the value passed since you won't have any changes. > 4c) Otherwise, set the property to something different so that 'flush' > will run. > > This was targeted toward building files in memory with ordering and I'm > going to try to get something properly written up this weekend that has > code examples. I apologize for not being able to post the code right now > but it needs to be properly cleaned up as an example. > > Also, this definitely does *not* get around the issue with dependency > failures. However, flush is *only* called during the last run of the > resource if there are changes to make so, unless you're opening connections > in 'initialize', then it should be safer. > > Basically, it stores all of the actions in the class variable and then > runs them if everything succeeds. > > It would be nice to have an automatically generated @@classname_classvars > for each provider for storing stateful metadata. > > So far this technique works with Puppet 2.X and 3.X. We'll see what > happens as more parts get rewritten. > > Thanks, > > Trevor > > > On Mon, Jul 15, 2013 at 11:24 PM, badgerious <[email protected]> wrote: > >> On Monday, July 15, 2013 11:53:10 AM UTC-5, Trevor Vaughan wrote: >>> >>> I just went to +1 this on #3946. I ran into a very similar situation >>> recently and was quite annoyed to find that the Providers didn't have a >>> 'finish' equivalent to the Types. >>> >>> Nan has a very good point that it needs to survive a dependency failure. >>> Almost like all downstream providers after the failure should be able to >>> look up a variable set in their parent path for failures to be able to make >>> adjustments based on being called after a failure vice a normal chain. >>> >> >> Hey Trevor, >> >> How are you handling this right now? You mentioned 'counting resources'; >> I'd be interested in an elaboration if you'd be willing to give one. >> >> Eric >> >> -- >> 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 post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/puppet-dev. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] > > -- This account not approved for unencrypted proprietary information -- > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
