I would like to see a dedicated group for this too. I have a few
opinions on the matter of language syntax and semantics.
My main frustration is the matter of slightly different methods for
declaring defines, nodes and classes.
Take these four examples a node, a define and the two class include/
initialize methods.
# A node
node uniquehostname {
#do stuff
}
# a define
mydefine {'uniqueName':
#do some stuff that can be run multiple times
param => 'val',
}
#Comments around 'uniqueclassname' may be used or ommited here
class {uniqueclassname:
param => 'val', #note comments on 'param' would mess it up here...
lame
}
#but comments are required here for 'module::class' syntax, else it
throws a syntax error
class {'module::uniqueclassname':
param => 'val',
}
#and finally
include uniqueclassname
I would like to see all syntax for instantiating a class define or
node be the same... an example:
node {'unquehostname': }
mydefine {'uniquedefinename': }
myclass {'module::classname': }
####
or if you prefer a more explicit syntax:
node {'unquehostname': }
mydefine {'uniquedefinename': }
class {'module::classname': }
Thoughts?
Nick
On Jan 7, 9:30 am, Nigel Kersten <[email protected]> wrote:
> On Fri, Jan 7, 2011 at 9:10 AM, R.I.Pienaar <[email protected]> wrote:
> > the overall point is there are features that are not designed in a way I
> > believe has everyones needs in mind and certainly hasnt had community input.
>
> I have to admit I was absent from the community when parameterized
> classes were introduced as my day job was taking all my time, but did
> we really *never* send anything out about it other than the patch
> submissions to puppet-dev ?
>
> I thought I'd seen proposals seeking feedback before 2.6.0.
>
> If this wasn't the case, then that was a screwup.
>
> As far as fixing the situation we're in now though, I've been pushing
> people to provide feedback on:
>
> http://projects.puppetlabs.com/issues/5046
>
> I would love to see your proposals for improving the situation there RI.
>
> > The language design process needs to be improved so that the result is less
> > inconsistent and weird.
>
> I agree. I think this is partly a consequence of us generally
> accepting patches without having serious curation and discussion of
> the consequences, and partly due to our community being largely made
> up of sysadmins who are time-poor, with small scraps of time here and
> there to devote to this sort of discussion.
>
> It's a difficult line to tread, as going too far in the other
> direction means we're rejecting too many contributions from the
> community, and no-one wants to be in that situation.
>
> So lets fix this.
>
> What do we need?
>
> A formalized group that takes the time to have oversight over language
> changes according to general principles we've agreed on?
>
> How official does this need to be? A full on committee with rotating
> roles and elections etc etc ? A volunteer group whose membership is
> completely ad hoc? Why aren't we getting the right feedback on the
> Dev/User lists when proposals are sent out?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
