Re: [Puppet-dev] was - Idea: Deprecation logs

[Alex Harvey]

On 11 April 2016 at 05:16, Eric Sorenson <eric.s...@puppet.com> wrote:

On Apr 10, 2016, at 2:05 AM, Alex Harvey <alexh...@gmail.com> wrote:

Hey Alex. I'm not sure I can respond point-by-point to the conversation, but I did want to chime in because you raise a lot of valid points and deserve a response. I've been the product manager for Puppet for the four years you're talking about and thus bear at least partial responsibility for the changes in question. 

Thanks for taking the time out to reply.  I feel that I should resolve some of the misunderstandings in the thread.  Maybe the dialogue is fruitful.

 

Thomas' mail earlier up-thread put this really succinctly:

For many people right now the configuration manager is the fastest moving target in their tool stack. 

We're trying to navigate a tension between, on one side, the push from Puppet as a business and config management as a discipline to close competitive gaps and add functionality; versus the other side, from existing customers and the wider ecosystem to stabilise and change as little as possible (excepting of course the bugs that personally affect whomever you're speaking with at the moment).

The major changes that you cite are actually all changes that I liked and agreed with.  I'm certainly glad that import and dynamic scoping has gone.

Others, however, don't appear to me to be aligned to either Puppet's business strategy, or to the community's interests.

An example might be abstract data types.  I know that the data types had issues, oddities and bugs around the implementation of hashes and arrays.  And a lot of that seems to have been fixed, and that's great, but we somehow ended up with a long list of strict, abstract data types.  And there's something about these new data types that just doesn't "feel" - to me, anyway - like Puppet any more.

And here's the thing: Puppet was already perceived to be a difficult language, despite the fact that it was intended to be an easy one.  So, I don't get how it's in Puppet's interests to inflict abstract data types on people who may not even have a computer science degree.  Some have come from shell, perl backgrounds, some may not have programming experience at all.

People are going to struggle with data types; I am sure of it.

We live in a world overtaken by Gen-Ys and Millennials who have grown up with Google, Facebook, and Apple.  We worship beauty, power and simplicity.

Ansible and Salt seem, somehow, to be chasing that ideal.  It does take half a day to understand these tools, and that just fits the impatience of the age so well.

But aside from being easy, Ansible has nothing going for it at all, and in fact it contradicts so much of what the DevOps movement was supposed to be about.  Infrastructure-as-code requires actual code, not a data serialisation format.  Ansible is ssh-in-a-for-loop - it's back again, and it's still just as fast!  Continuous integration of your Ansible doesn't exist because there's no language to test.  System-testing-is-all-you-need is here, because system testing is all you can have in Ansible.

I think it's a great big programming anti-pattern, it's ugly as all hell, certainly nothing Apple would be seen dead near, and yet it's taking over.  How?

Here's some data right here: (Right Scale State of the Cloud Report, Feb 2016):

​

To make it worse, if we factor in all the planned migrations away from Puppet that are in train, I suspect that this chart is being kind to Puppet.

Why is this happening?

I believe that in order to "encourage" open source Puppet users to buy Puppet Enterprise, Puppet has deliberately made Puppet difficult.  And I'm sure the problem is somewhat recognised internally, and Puppet 4 did seem to go some way to make Puppet easier.

I'm just really worried that Puppet's reverting to its old ways.

The open source community is the life-blood of Puppet, and I don't believe that chasing the "white space", the dinosaurs as RI said, is in fact a good business strategy.  The open source community put Puppet where it is, and I believe they'll take it down again if Puppet doesn't listen.

I really hope I'm wrong, because I don't want the dream of convergent, declarative configuration management to die with Puppet.

​If I may, I think Puppet is taking far too much feedback from Puppet enthusiasts (e.g. Puppet Test Pilots, speakers at conferences) and not enough from all the people who don't bother filling in surveys, who don't go to Puppet Camp, and are quietly as frustrated as all hell with Puppet.

I'd love to hear suggestions for how to get feedback from people who won't talk to us through any of the channels they have available to them :-)

Yep, I walked into that one. :-)  

Look, reach out to them.  Somehow, I wish Puppet somehow could be more involved in the open source sites.  I'm sure you know where they all are.  Be available to them.  

[Eric Sorenson]

On Apr 11, 2016, at 9:17 AM, Alex Harvey <alexh...@gmail.com> wrote:

An example might be abstract data types.  I know that the data types had issues, oddities and bugs around the implementation of hashes and arrays.  And a lot of that seems to have been fixed, and that's great, but we somehow ended up with a long list of strict, abstract data types.  And there's something about these new data types that just doesn't "feel" - to me, anyway - like Puppet any more.

And here's the thing: Puppet was already perceived to be a difficult language, despite the fact that it was intended to be an easy one.  So, I don't get how it's in Puppet's interests to inflict abstract data types on people who may not even have a computer science degree.  Some have come from shell, perl backgrounds, some may not have programming experience at all.

This thread kind of tapered off, and there's stuff that I'm pretty sure I cannot address in a satisfactory way, but I did want to tuck into this point a bit.  There's an interesting balance to strike because — as you note — the puppet language was intended to be simple. "It ought to look and feel more like a nagios config file than a scripting language", I recall Luke saying, early on. But as time has passed, users have demanded it fulfill more and more complex tasks, like setting up OpenStack, one of the most hellaciously complex distributed systems ever invented by humans.  (I kid, I kid, just a bit) And using a tool whose sophistication is mismatched to the task leads to hacky awfulness; you're going to do what you must, but it won't be pretty. The type system and iteration syntax are a response to that situation, in the same way that parameterized classes were a response to the dearth of reusable Puppet code before 2.6; similarly I hope that in time, as style standards, best practice, and the syntax itself evolve, the new stuff will come to feel as Puppet-y as class parameters do today. 

Aside from the few syntactic changes that the type system imposes on existing code, like forcing quoting of numeric file modes, all of the new stuff is completely opt-in. So I'd (gently) dispute the assertion that they're inflicted on everyone as an early barrier to using puppet — a new user could go a long way downloading forge modules, composing configuration with hiera and/or roles+profiles, writing their own modules and classes, and generally being successful with the product, without needing to understand Variants, Enums, and the rest. Conversely, the existence of those things makes it easier for module authors to represent concrete API promises, so previously impossible things become easy, like a GUI that accurately represents a Boolean class parameter as a true/false toggle rather than a text field.

I believe that in order to "encourage" open source Puppet users to buy Puppet Enterprise, Puppet has deliberately made Puppet difficult.  And I'm sure the problem is somewhat recognised internally, and Puppet 4 did seem to go some way to make Puppet easier.

This is plainly untrue. Even setting aside Hanlon's Razor and assuming the most Machiavellian profit motive, it would be folly to adopt such a strategy. Most of our customers come to Puppet Enterprise after some experience with open source, so relying on commercial differentiation that turns them away at the door would be suicidal. Now, we *are* painfully aware that the overall experience of starting out with Puppet is harder, not only than other competing solutions, but than Puppet itself used to be. Any spiky edges that cause users frustration between "hey I think I need some config management in my life" and "look there's Puppet doing just what I needed" need to get ground down into a smooth frictionless polish, and that goes equally for people who encounter Puppet via open-source or PE. 

All this is to say, it's highly likely that the current state of the language is not going to be its final state. Some things are certain to be wrong and need to iterate to improve. Puppet's reach is so much broader than it was five years ago, the ripple effects of changes that improve the experience for one set of users might actually make things worse for another set, but we just can't know until we get out in the world and see what happens. It's a tough landscape to navigate and I value guidance like this immensely.

Eric Sorenson - eric.s...@puppet.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

[Luke Kanies]

Fantastic response, Eric, couldn't have (and obviously didn't) said it better myself.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5FA8BE6D-E1A6-400C-BEA3-9B6907CF65AC%40puppet.com.
For more options, visit https://groups.google.com/d/optout.