----- Original Message -----
> From: "John Gelnaw" <jgel...@gmail.com>
> To: "puppet-users" <puppet-users@googlegroups.com>
> Sent: Monday, 9 January, 2017 20:14:00
> Subject: Re: [Puppet Users] Over-engineering rant
> On Monday, January 9, 2017 at 10:10:08 AM UTC-5, R.I. Pienaar wrote:
>>
>>
>> so we're on the same page are you just saying in general the NTP module
>> has too much
>> going on and its too huge for a "simple" piece of software?
>>
>
> Mostly, it was the unexpected syntax. Somehow, I completely missed any
> references to data typing. I'm not even *opposed* to it-- although there's
> a very lazy part of me that says it needs to remain optional. :)
>
> While the puppet 3 version is, quite frankly, hideous, I understand why
> it's that way, and it's at least formatted nicely, so it's easily read.
>
> The puppet 4 version looks cluttered (even though it's much simpler, it
> APPEARS more cluttered because it's not a table any longer), and was a
> paradigm shift I was unprepared for.
>
yes, today we have:
class foo(
String $thing,
Boolean $other_thing,
Enum[Boolean, String] $yet_another_thing
) { }
my early feedback on this was from a readability perspective the thing I
care for most is the variable name and like in this class the var names
are obscured as you're immediately drawn to the var types and not their
names
Indention would have helped so there is a column of var names all below
each other, but better would be:
class foo(
$thing String,
$other_thing Boolean,
$yet_another_thing Enum[Boolean, String]
) { }
Here I can see what the variables are and care for the rest later, there
is a ticket and I know it was planned to support both, not sure where that
is
>From a system perspective we can have MUCH better auto generated docs now
that it knows what type a variable is and user interfaces like the console
can eventually produce much better user interfaces because they can prompt
for things intelligently
> But reading through it makes sense.
>
> Although-- I think I'd consider (optionally) moving the params to an
> external file, for readability, if nothing else.
>
> In both the puppet 3.x and 4.x examples, you've got a whole lot of
> information jammed into the "first line" (that has 50+ parameters) that can
> overwhelm a novice user.
>
> Whatever happened to yaml-in-modules as a concept? I'd think using
> something like that for parameter definitions would be a much cleaner
> approach.
look at data/* in the module, you still have to define the parameters so
it knows to look them up, I think having the parameters in code is best
but the data and configuration of them (how to merge etc) in data is most
usable, especially as the data aspect is optional etc
>
> Maybe something like:
>
> params.yaml:
> classes:
> ntp:
> config_epp:
> type: string
> required: false
>
>
> ... but that may be too much caffeine talking. ;)
>
>
>> and Data now uses Hiera, its a LOT LESS code in Puppet 4 and fewer
>> dependencies
>> etc
>>
>> Just want to understand the actual complaint part of this distinctly from
>> the rant
>> part of this mail thread.
>>
>
> Not even sure it was a complaint-- Just a bit of culture shock as an
> unknown feature crept up on me.
>
> Heck, you should have seen me trying to find out what the "@@" syntax meant
> (puppetdb has been somewhat unstable until recently in my environment, so
> I've never spent much time on it, and didn't have a need for exported
> resources).
>
> Puppet, as a language, however, has been a moving target for years-- at one
> point in the 3.x days, I had to switch to a fixed version to keep my puppet
> server from becoming incompatible with my existing code-- but that also
> meant I couldn't easily get security updates, because puppet doesn't
> understand "Update to latest version below version 'x'". Things have
> improved considerably, but it's a still a full time job keeping up with the
> changes.
4 has been a sea change from the old ad hoc approach to a whole standardisation
and rationalisation perspective, the outcome is much better and actually
standard
and documented and with a proper language specification and you can find out how
things work - a HUGE improvement, but yes it's practically a brand new language
5 which isnt that far off will be very very smooth sailing as the language
changes
are done - apparently :) time will tell.
> But if you want rants:
>
> * why won't my puppet agents download a new CA from the puppet master
> when I update it? Why do I have to manually delete the "cached"
> /var/lib/puppet/ssl/certs/ca.pem file in order to get the new ca.pem file
> downloaded? That's not cached, that's stored. ;)
Because if i can convince your client to connect to $evil_ca, then what?
How's it to know its a new legit ca and not a new bad ca?
> * similarly, having to manually delete / renew agent certs is painful
> because you have to be logged in on both the agent and the master-- an
> auto-renew feature would be nice.
likewise.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/812678210.354205.1483990767168.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.
