On Fri, Dec 9, 2016 at 5:45 PM, Trevor Vaughan <[email protected]> wrote: > This makes sense but it *is* compile order dependent though. Therefore care > has to be taken in ensuring that all shared_data are available prior to full > resource realization in the catalog. > > This is why the ordering relationship matters, not for any client side > reason. > > Basically, it would mean deferred realization of catalog resources until the > end of catalog processing.
You wouldn't want or need to use explicit resource ordering relationships for that, though, since those mean something different. Presumably, whatever shared_data/ephemeral resources/etc are available would be determined by the type registering them in some way, so you could automatically define these compile-time dependencies similar to how, e.g., file resources automatically have a resource dependency on the file resource for the directory they are contained in. > Trevor > > On Fri, Dec 9, 2016 at 1:13 PM, John Bollinger <[email protected]> > wrote: >> >> >> >> On Thursday, December 8, 2016 at 9:29:00 AM UTC-6, Trevor Vaughan wrote: >>> >>> So, in theory, ephemeral resources would only have relationships on items >>> that need them for data and/or building purposes. >> >> >> >> Meaning that ephemeral resources / shared_data will not have relationships >> at all, then? Because relationships have no significance during catalog >> building; they affect only catalog application. If ephemeral resources are >> not to be delivered to clients, then relationships among them (as currently >> construed) cannot be meaningful. >> >> Alternatively, if indeed a complete break is made between resources and >> shared_data, then perhaps there will be scope for relationships among >> shared_data objects to affect catalog building. >> >> >> John >> >> -- >> 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/51388e3d-9b1e-47c3-b233-78a2678782b4%40googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 > > -- 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%2BFoWL-TDxv0nS1zG%2BZhJv656AMckvP7Qt6sE6MBcS78ObRw%40mail.gmail.com. > > 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/CAHTHiAECWPaPhzdNY68dNAScV9W4gKM%2B%2Bdob8G%3DWzVd0wm%3DxXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
