On Sep 3, 2013, at 12:00 PM, Eric Sorenson <[email protected]> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
