>From my perspective I always kind of feel like we lack a bigger goal
to aim for when we discuss these items - and therefore these
incremental changes are myopic in nature - they focus on fixing one
issue but I fear without a bigger picture plan anything incremental
could be dangerous. I've mentioned this before I think when discussing
other incremental changes. We all have our pain points, but no one (or
collective) to collect all the pain points and devise a goal. Such a
goal would of course be a major revision - but once you see the
direction in its entirety then you can see where the incremental
changes need to be with more certainty and even start thinking about
backwards compatible changes to get there.

I would prefer to see a high-level specification of where we want to
be in a year, two years ... let it be nutted out in
workshops/discussions ... and then develop against it. Maybe I'm
wrong, and others feel they do have a high enough perspective of how
it should _all_ ultimately fit together - just expressing my 2p/2c.

Of course there is the problem of theoretical conundrums, whereby all
the talk in the world won't answer the question - it needs to be
prototyped and tried - and this is part of what we should do as well I
guess :-). If you can't write a full end-to-end manifest (and set of
custom + provided library of modules) that mimics a full build with
multiple applications like in the real world with such a proposal -
then its not complete.

On Tue, Apr 17, 2012 at 11:36 PM, R.I.Pienaar <r...@devco.net> wrote:
>
>
> ----- Original Message -----
>> From: "Andrew Parker" <a...@puppetlabs.com>
>> To: puppet-dev@googlegroups.com
>> Sent: Tuesday, April 17, 2012 11:21:28 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>>
>>
>> On Apr 17, 2012, at 1:31 PM, R.I.Pienaar wrote:
>>
>> > ----- Original Message -----
>> >> From: "Andrew Parker" <a...@puppetlabs.com>
>> >> To: puppet-dev@googlegroups.com
>> >> Sent: Tuesday, April 17, 2012 9:21:23 PM
>> >> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>> >>
>> >> Other than because of bugs, facts are immutable, they are just
>> >> shadowable. We can end up with the illusion of mutation of
>> >> variables
>> >> because of the strange interactions of inheritance with variable
>> >> lookup and sequence of evaluation. In order to get rid of some of
>> >> this confusion, I suggested an alternative, which is to remove
>> >> node
>> >> from the language.
>> >
>> > I think we are kind of generally agreed that nodes are bad, but we
>> > have
>> > no idea what might replace them to meet the current needs right
>> > now, so
>> > that might be some way off.  Certainly its not an incremental
>> > improvement
>> > thats easily deprecated - these special vars though would be.
>> >
>> > And simply removing them will not solve the basic problem, i think
>> > much
>> > of this was covered in the ticket referenced earlier.
>>
>> As far as I understand removing node from the language is already
>> well supported since it can be emulated with constructs like:
>>
>>   include $hostname
>>
>> or
>>
>>   case $hostname {
>>      /foo.*/: { include foo::role }
>>   }
>>
>> The problems discussed in the ticket seem to revolve more around
>> settings and facts which can be considered orthogonal to the issue
>> here if we just remove node.
>
> the basic problem I elude to is that there are lots of kinds of variables
> represented in competing form.  In ways that is undiscoverable and not
> obvious. The 'top scope' tend to have facts, variables set in site.pp,
> variables from ENC and potentially depending on puppet version variables
> set in node blocks. And its impossible for anyone to say "what are all the
> facts" or "what are all the ENC provided variables" and so forth yet these
> are questions people want answered.
>
> Simply removing nodes does not resolve the above - it resolves on of the
> above by omitting it without creating a really viable alternative. Leaving
> the larger problem of confusing variable sources unaddressed.
>
>>
>> If this is too drastic of a change for now, then maybe the best
>> course of action is the leave node scoped variables in a "crippled"
>> state. I think the best course it to remove them from the language,
>> but there may not be enough consent to that. Independently of that
>> we can try to tackle the other issues you are bring up, but not
>> right now.
>
> I mostly dont want to rush headlong into abandoning node without extensive
> community discussion.  It's a key construct and people do lots of weird and
> wonderful things in them. I can quote many many problems with the suggestions
> above where they just wont be good enough or provide matching feature sets,
> more extensive design is needed.
>
> Its something I dont think we can resolve for Telly probably, but we could
> make progress on the easier problems.
>
> Anyway, we are going around in circles, I think I said what I have to say on
> the subject anyway.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to