Sorry, I think you're over complicating this. The fix should require no changes to syntax or usage; merely the cessation of use of the anchor pattern.
Containment should continue to mean what it has for years, which is generally class-to-resource and almost never class-to-class. This is easy to see by looking at the first generated 'dot' file (I don't remember its name, and I'm on a playground so can't look it up). We don't have a problem with the definition or syntax around containment; we have a bad implementation for combining containment and dependencies that causes classes that contain no resources to have zero affect on the graph, regardless of dependencies. And yes, fixing this bug will absolutely change the behavior for those areas affected by the bug. If we didn't desire that change, we would call it a feature, not a bug. (Worthy of historical note: class inclusion used to result in containment the first time but not subsequent calls. I changed this behavior around 2.6 or so, because I couldn't find any good reasons for it and it made things much more complicated. I believe zero people noticed the change.) -- Luke Kanies | +1-615-594-8199 | http://about.me/lak On Aug 28, 2013, at 3:57 PM, Andy Parker <a...@puppetlabs.com> wrote: I just reread your email and realized that I said "no", but my final paragraph is the real response to exactly what you asked. :) So yes, adding the relationship can cause the order to change. On Wed, Aug 28, 2013 at 3:56 PM, Andy Parker <a...@puppetlabs.com> wrote: > On Wed, Aug 28, 2013 at 3:22 PM, Luke Kanies <l...@puppetlabs.com> wrote: > >> On Aug 28, 2013, at 12:38 PM, Andy Parker <a...@puppetlabs.com> wrote: >> >> On Wed, Aug 28, 2013 at 10:20 AM, Luke Kanies <l...@puppetlabs.com>wrote: >> >>> On Aug 28, 2013, at 8:45 AM, Andy Parker <a...@puppetlabs.com> wrote: >>> >>> > * #8040 - anchor pattern. I think a solution is in sight, but it >>> didn't make 3.3.0 and it is looking like it might be backwards incompatible. >>> >>> Why would it be incompatible? >>> >>> That implies that we can't ship it until 4.0, which would be a tragedy >> >> worth fighting hard to avoid. >>> >>> >> The only possible problem, that I know of, would be that it would change >> the evaluation order. Once things get contained correctly that might cause >> problems. We never give very strong guarantees between versions of puppet, >> but given the concern with manifest order, I thought that I would call this >> out as well. >> >> >> Do you mean, for 2 classes that should have a relationship but currently >> don't because of the bug (and the lack of someone using an anchor pattern >> to work around the bug), fixing that bug would cause them to have a >> relationship and thus change the order? >> >> > No that shouldn't be a problem. I think we will be using making the > resource syntax for classes ( class { foo: } ) create the containment > relationship. That doesn't allow multiple declarations and so we shouldn't > encounter the problem of the class being in two places. > > >> That is, you're concerned that the bug has been around so long it's >> considered a feature, and thus we can't change it except in a major release? >> >> > More of just that the class will start being contained in another class > and so it will change where it is evaluated in an agent run. That could > cause something that worked before to stop working (it only worked before > because of random luck). I'm also, right now, wondering if there are > possible dependency cycles that might show up. I haven't thought that one > through. > > >> -- >> Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | >> +1-615-594-8199 >> >> -- >> 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 post to this group, send email to puppet-dev@googlegroups.com. >> Visit this group at http://groups.google.com/group/puppet-dev. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Andrew Parker > a...@puppetlabs.com > Freenode: zaphod42 > Twitter: @aparker42 > Software Developer > > *Join us at PuppetConf 2014, September 23-24 in San Francisco* > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out. -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
