On Fri, Dec 9, 2016 at 5:45 PM, Trevor Vaughan <tvaug...@onyxpoint.com> 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 <john.bollin...@stjude.org> > 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 puppet-dev+unsubscr...@googlegroups.com. >> 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
