On 2014-14-03 3:25, Trevor Vaughan wrote:
So, it sounds like we're getting everything we wanted! That's great to hear.
So, I suppose that I should have been clearer. We are starting to label
all variables and class calls with $::name to ensure that the full
removal of dynamic scoping works properly. While more verbose, I find it
to be much more clear and easier to maintain overall.
Glad to hear that.
What I'm actually doing is to use class variables in my providers so
that I can bundle up all of my resource applications until the last one
has passed through the catalog. This explains it with working examples
https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/.
This works fine as long as there is nothing else that depends on the
result (since it only appears at the very end).
It appears to be one of the more popular (of the limited) posts on my
site right now and others that I've spoken with have expressed interest
in doing this type of thing so anything that makes it easier/cleaner
would be most welcome.
Thanks,
Trevor
Interesting, it is an orchestration of sorts of all the resources
managed by the type / provider. The orchestration itself is simple;
simply do something with all of them at the end (on flush).
While we have ideas for this kind of fine grained orchestration, this is
not slated for inclusion in puppet until later in the 4x series. I don't
yet have anything written up - there is simply a ton of other things to
do first...
However, jumping ahead - the idea is roughly that providers have access
to a state machine and may queue up things to do for later, and that it
may be doing things in parallel, have shared steps (like in your example
to read the file), etc. Will come back to this topic later...
Meanwhile, thanks for sharing the example - it illustrates the need for
fine grained orchestration well - a Resource is too heavy, and there is
no supported way to break it up into smaller Resource-ettes/tasks. While
you could write out each line to the file system (and use it to maintain
state), and then later have another Resource type pick them up and apply
them to the target file, that quickly snowballs into a mess of resource
dependencies, overhead in logging and what not...
Regards
- henrik
--
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/lfts09%24eoc%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
