----- Original Message -----
> From: "Alex Harvey" <alexharv...@gmail.com>
> To: "puppet-dev" <puppet-dev@googlegroups.com>
> Sent: Sunday, 10 April, 2016 11:05:49
> Subject: Re: [Puppet-dev] Re: Idea: Deprecation logs
> On 10 April 2016 at 03:59, R.I.Pienaar <r...@devco.net> wrote:
>>
>>
>> Not really sure I follow most of this rant.
>>
>
> Yes, fair enough. It was a bit of an uncalled-for rant.
>
>
>> In what relation does the switch to clojure even matter? There is no user
>> visible clojure code, you don't need to know it to extend puppet etc. It's
>> literally internals you never need to poke at
>>
>
> I guess what this shows is that even when changes don't appear to be
> user-impacting, they are. This guy was asked what his favourite CM tool's
> biggest pain point was; and he cited Clojure, and to be sure, I also don't
> understand why Clojure would be an issue. But sure, your point is taken.
Indeed and it's valid, the java eco system has the ability to provide
really amazing admin insight and tooling but requires some learning
What doesn't help is that Puppet chose to make what's basically core required
abilities to achieve this visibility like the detailed performance metrics be
PE only instead of finding higher level features to make PE only. This will
really hurt the Open Source users rather than just not giving some features they
might not need and others would be willing to pay for.
>> Though from what I can tell puppet4 adoption is indeed pretty bad - unless
>> you're counting the many many paying customers who afaik have been on 4 for
>> quite some time. And that's quite the very large amount of people now.
>>
>
> Every second person I speak to in Sydney tells me "Puppet is dead, get over
> it".
>
> And the complaints I hear are always the same:
>
> - Puppet is too hard
> - Too hard to debug
> - There are bugs that never get fixed
> - And instead of bugs getting fixed, there are frequent breaking changes
>
> We are bleeding users and, not that I'm particularly in the loop but from
> the outside looking in, we seem to be in denial.
Lets look at these from the perspective of a deprecated and now removed
features.
The import keyword lost most of its use when modules were introduced (0.25?)
except for 'import nodes/*.pp'. It should have been dead ages ago.
But in order to maintain backwards compat with pre-module people it was kept,
but
it's a deeply deeply flawed feature:
- it doesnt do what it seems to suggest it does (puppet is too hard)
- it breaks intermittently in impossible to detect and remedy ways (too hard
to debug)
- it has bugs where it would result in inconsistent outcomes, and its so
deeply flawed as to be unfixable, hence unfixed bugs with it
The very act of keeping it is the cause of the problems you list, yet the
same class of user who complain about it refuse to do the work to let Puppet
remove it and thus solving their exact problems.
Worse, it's use has been discouraged for YEARS. But again the same class of
user who moan about 'breaking' things are the ones who refuse to heed warnings
in the documentation and instead approach complex software from a point of
solving an immediate problem therefore its good rather than a long term view
as the tool managing the foundation of your infrastructure require. I who do
read the documentation have written my pre 4 code to avoid the things now
being removed and when moving to 4 had to change 1 thing - quote my file
modes.
This pattern holds true for almost all the deprecations in the last while,
they are either things we've replaced with better things literally years ago
but kept to pander to these change averse minority or they are things that were
experimental or just new new and turned out to be bad ideas. Don't forget that
in many ways Puppet was trail blazing, there's going to be bad ideas that's
not worked out and better deleted. Yet Puppet has kept these for YEARS.
But in all cases them being there literally hurts everyone. I can tell you
I must have spoken with at least 100 people over the years who struggled with
issues caused by import, but because its in the docs and it seems simpler
than modules new users use it and everyone suffers as a result.
Now of course this hurts, but the team have now looked at every feature in
Puppet and considered it and where it was possible to define their behaviour
the behaviour is formally defined in the puppet language specification or
where the behaviour was just irrevocably broken and unpredictable they were
deprecated or the just critical behaviour was kept (weird shit removed) or
something new was made - like directory environments which fixed both
critical short comings in environments and removed the need for import.
Both terrible in their old state.
I think the outcome is significantly better and its better because finally
someone somewhere has said the change averse minority of people who hang out
at free events and rant to their echo chamber can go fuck themselves, and
the outcome for us who don't fit in that echo chamber is a significantly
better puppet, so thanks for that.
> I remember Nigel saying after Puppet 3 was released that Puppet would now
> stabilise. That was in 2012, and yet here we are in 2016 and we have so
> many deprecations coming that a dedicated deprecation log file to keep
> track of them all seems like a good idea.
seriously? you have software that is stable for FOUR YEARS in modern IT
and kept features that was deprecated SEVEN YEARS ago around. In what
world is that not stable? For god sake you can get the very latest
Puppet 4 on REDHAT FOUR. Who else does that?
Now since they adopted semver and 2 or 3 years ago started down a route
to deprecate and remove very very old rubbish features they've been extremely
careful and considerate when deprecating things and should be commended
for that. They can't come to your computers and do the work for you though
to get modern software, if as a user you refuse to do your side to ensure
there's a stable whole do not complain when the other half of the equation
doesn't hang around waiting for you to do something.
> 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 say do the exact opposite.
And I should prefix this with stating in case it's not obvious that I am not
employed by Puppet and haven't been since 2013.
There's a often quoted stat that 80ish % of large companies DO NOT EVEN USE
ANY KIND OF CM.
Think about that. 80% of companies do not use CM. They are literally like
the anti intellectual who are hand managing sometimes 1000s of machines.
There needs are growing acute by the day and they are willing to pay big
money to solve that problem once they hit the inevitable wall.
Now these small minority of change averse people who have literally created
the problem you described? They're a rounding error in the rounding errors
of people who matter.
When you're talking about a company with over 300 (i think?) headcount, who
lands deals equally many many millions of $ for a single install, I can't see
how you seriously suggest this is the way to go?
There's a giant mountain of gold at the bottom of the rainbow in the 80%, and
they do not want cutting edge. They do not want a buggy unpredictable, hard
to debug Puppet. They're willing to pay for a well specified and well designed
coherent product. That's what Puppet 4 is. Sure in moving to it we'll loose
some class of user - I for one am glad to be spending less and less time talking
to the kind of user who refuse to change. If you think the old dudes in the
basement feeding the mainframe are where you want to be, continue to spend time
with these change averse people.
I'd wager that a lot that drives moving from Puppet to elsewhere is less about
these problems you listed and more about the realization that the future is
not about mogrifying long running machines and more about orchestrating
deployments of whole pre-tested artefacts.
Ansible and such is a reasonable step in that direction when you're a old skool
shop looking to make a small step forward. But when you look at the new stack
you'll see a few things:
- none of it is 'free' in the old sense of the word, very few parts of the
new stack is made by some hand full of dudes in their basements
- today a lot of it needs configuration but every day we move closer to a
world with new operating systems and new patterns (see CoreOS and similar
from every major distro) that simply do not have the problem CM fixes
- the tools are self assembling, self configuring, have strong opinions and
do not need environmental level changes.
- very importantly their users are willing to adopt the strong opinions unlike
sysadmin who think they bring value by hand crafting an apache config in
what they believe is somehow superior.
Everyone is into this, old distros, old storage vendors (hyper converged) etc
It's where the future is. Even if its long away, its coming. Puppet is not
dead at all you state - but ther's a real risk that it will not be relevant
to a distant future (in IT terms, much sooner than you think in man years).
I've often said 'the best CM is as little as possible CM' and the future is
embracing that. Puppet is both the best and the worst thing to happen to
systems
people. Best because it solved a problem that was very very hard to fix -
configuring systems. Worst because it bought that terrible core broken pile
of crap that needs deep configuring to the tune of sometimes 1000s of resources
per machine a 10 to 15 years lease of life. Time that should have been spent
inventing a new approach to solving our problems. Finally the new stack
companies
are doing this.
Your change averse friends should ask themselves not why is the software
changing
but rather why is a whole new class of startup out there that does not feel
their
oppinions have any merit.
Puppet have unfortunately not embraced this on any significant level. I deeply
believe the statement being thrown around that in the future the hypervisors and
such will still need config and so there is always a future for CM tools is
very wrong. The new initiatives to attempt to show Puppet is relevant when
configuring tools like k8 and so forth is not going to have a long term set
of legs.
The future is in orchestrators and tools like those put out by Hashicorp, CoreOS
Docker, Google (k8) etc. And not at all in what we know. Puppet need to figure
out how to do something new there.
That future is "far" away though, 5 to 10 years and as stated there's a giant
mountain of gold to farm at the end of the shitty enterprises rainbow so the
- to be generous - baby steps Puppet is taking in this orchestration space is
not at all interesting or exciting to me. But those 80% do not want interesting
or exciting so where it's heading is perfectly fit for purpose, just not a
purpose
I believe will exist in the future on the modern side of computing, those who
need what we have today will be like todays mainframes.
So my suggestion would be to not do what you suggest at all instead stop
engaging
with the change averse dinosaurs heading for the endangered list as a place to
find new features. Be a great Puppet to sell to that 80% and invest in
creating
a team dedicated to engaging with the new generation to be sure there's a
future.
10 years sounds like a long time but it's actually both long and short. Short
time for a large multi 100 head count company to do anything in and very very
long when considering the rate of change in todays IT.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/1678839111.542998.1460307113403.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.
