On Sep 3, 2013, at 12:00 PM, Eric Sorenson <eric.soren...@puppetlabs.com> wrote:
> Replies inline; I've butchered the quoting but will try to keep the
> attribution correct.
>
> [John Bollinger] Part of my premise here is that you cannot reasonably infer
> from a class declaration alone -- regardless of the form of the declaration
> -- whether its declaring class intends to contain the declared one. There
> has to be something to distinguish the contained case from the non-contained
> one.
>
> This was a valuable piece of insight, thanks.
Totally agree; this is why we were getting dependency cycles before we changed
this.
> [Luke] Maybe PuppetDB makes this all irrelevant because it actually builds a
> graph that contains both, and makes that graph easily accessible, but… if
> it's good for PuppetDB, why isn't it good for Puppet?
>
> We absolutely plan to consolidate down to one catalog format, which should be
> the one used by PuppetDB. I think the graph refactoring work you'd like to
> see is desirable but should come as a byproduct of writing new code to
> produce and consume these, rather than trying to shoehorn those changes onto
> the anchor pattern work.
Until recently, my understanding was that the bug was caused by the whits
stuff, and I was advocating for fixing all of that at once.
It looks like we shouldn't need to touch the catalog stuff at all to make this
work, so I agree. Is there a ticket out there for the catalog format
refactoring?
> [Andy] Here are the possibilities:
> * resource like syntax for classes expresses containment:
> class container { class { contained: parameter => value } }
> * a function declares the class *and* expresses containment
> class container { contain(contained, { parameter => value }) }
> * a function expresses containment, but does not declare the class
> class container { class { contained: parameter => value }
> contain(contained) }
> * a new "resource type" expresses containment
> class container { contain { contained: parameter => value } }
>
> I'm most in favour of number 3 here, a function to express the containment as
> a separate thing to declaring the class.
Why? What are the benefits of this, and downsides of the other options?
> [Nick Lewis] A 'contain' function was the decision we came to last time I was
> involved in a conversation about this. That turned into ticket #13045, which
> was closed with the decision that it should be fixed in Puppet
>
> [Luke] I'm in favor of it as a simple, optional, backward-compatible fix.
> Basically, if you're using the anchor pattern now, you can use the contain
> function instead, and properly represents what's going on.
>
> +1
How is it that we're coming to the same decision as we did a year ago, everyone
seems to agree, most of the players are the same, yet we didn't just fix this a
year ago?
Or, even, why didn't someone just write the 2 line function and start using it?
--
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.
