Idea: Deprecation logs

[Rob Nelson]

Happy Friday, everyone! This morning I had some semi-intelligible thoughts about feature deprecation in Puppet, specifically because I got bit with an upgrade issue last night. We do user stories a lot at work, so I'm going to frame it that way. I was curious what other opinions people have on this problem and how it can best be addressed. Thanks!

Problem

When a user updates puppet components (server, agent, puppetdb, etc.), a number of new features and options are typically made available, in addition to the default location of some files being changed. Older features, options, and file locations (collectively 'features' for simplicity) are considered deprecated, to be removed in some future version. Alerting the user of this is challenging for a few reasons.

1. Deprecation messages in puppet runs are noisy and most users disable them as quickly as possible, never to be seen again.
2. Moving the messages to the component's log results in a bunch of needles being added to the needlestack.
3. At the time of deprecation, it is usually impossible to determine what future version will have no longer support the deprecated feature, so users cannot plan for a timely removal of the feature.
4. When upgrades occur, deprecated or changed features often result in failure to start/run, failure to properly apply entire catalogs due to the loss of some components of it, poor or confusing logging about what caused the issue, etc.

Solution

Deprecated features can each be given an identifier (ID, String, etc). Use of a deprecated feature can go to a specific log within the component or general puppet logs that includes the timestamp, identifier, and relevant identifying information such as catalog or configuration file name and line. An additional tool can be provided for users to review this log and provide the number of and last timestamp indicating usage of the deprecated feature, along with the entirety of that log entry.

Each deprecated feature identifier can easily be searched for in Puppet Labs documentation, Jira tickets, and search engines to help determine how a user may address the issue prior to upgrades. After an upgrade where a deprecated feature is removed, the identifier can be displayed directly to a user in addition to the log, and any interactive upgrade can review the recent logs (i.e. 24 or 48 hours) and highlight features removed in the the last MAJOR or MINOR update.

It is understood that newer versions that do not support a feature will also no longer be able to detect the deprecated feature and provide accurate logging of the missing feature that is causing the fault. By separating out the deprecated messages into a separate log and providing a simple tool to search the logs, the user is empowered to easily find the use of the deprecated features and can correlate the IDs with release notes and such as well as the time of upgrades.

Rob Nelson
rnel...@gmail.com

[Thomas Gelf]

Hi Rob,

nice proposal, would definitively help people to deal with the stated
problem. Another approach could be to break and deprecate less things.

Sure, I'm just kidding ;-) I love moving things forward. But you know,
there's a grain of truth in every joke. We should not forget about the
fact that by the end of the day we are talking about a tool designed to
manage configuration.

For many people right now the configuration manager is the fastest
moving target in their tool stack. Your proposal is telling me that we
have a cfgmgmt tool struggling with the amount of deprecations it
produces. Sad story. We work for the tool, not the other way round.

Cheers,
Thomas

[Rob Nelson]

Yes, it should probably break less. But change is eternal, so it's going to happen and its best we deal with it. It's not like this problem is relegated to only CM tools! If something like this happens with Puppet, it may end up being a good model to point other vendors to.

--
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/ncn1cd%24987%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson
rnel...@gmail.com

[Martin Alfke]

+1

A tool/separate log would be nice.
I now many puppet installations where people are not locking into their log files and where they review their deprecation warnings.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT-k6cg8WEyR0qaeaf2a_qR2ghmhoeRvXE8u%3D53ueAJXeQ%40mail.gmail.com.

[Erik Dalén]

On March 18, 2016 at 19:12:08, Rob Nelson (rnel...@gmail.com) wrote:

Happy Friday, everyone! This morning I had some semi-intelligible thoughts about feature deprecation in Puppet, specifically because I got bit with an upgrade issue last night. We do user stories a lot at work, so I'm going to frame it that way. I was curious what other opinions people have on this problem and how it can best be addressed. Thanks!

Problem

When a user updates puppet components (server, agent, puppetdb, etc.), a number of new features and options are typically made available, in addition to the default location of some files being changed. Older features, options, and file locations (collectively 'features' for simplicity) are considered deprecated, to be removed in some future version. Alerting the user of this is challenging for a few reasons.

1. Deprecation messages in puppet runs are noisy and most users disable them as quickly as possible, never to be seen again.

The proposed solution for this is already to add the strict mode. So you can basically opt in/out of deprecation warnings.

2. Moving the messages to the component's log results in a bunch of needles being added to the needlestack.

IMHO the deprecation warnings aren't visible enough. Most of them are just logged on the puppetmaster side. So there is no way for a user to see them (on the agent side).

This is one of the major pros of masterless at the moment in my opinion, that you can easily see the log messages from the compilation as well. It would be really good if the puppetmaster could ship them to the agent as well.

3. At the time of deprecation, it is usually impossible to determine what future version will have no longer support the deprecated feature, so users cannot plan for a timely removal of the feature.

Isn't this always the next major version? That is kind of the point of semantic versioning to make it easy to know which versions are breaking compatibility.

4. When upgrades occur, deprecated or changed features often result in failure to start/run, failure to properly apply entire catalogs due to the loss of some components of it, poor or confusing logging about what caused the issue, etc.

Well, that depends on how often you do major version upgrades.

Solution

Deprecated features can each be given an identifier (ID, String, etc). Use of a deprecated feature can go to a specific log within the component or general puppet logs that includes the timestamp, identifier, and relevant identifying information such as catalog or configuration file name and line. An additional tool can be provided for users to review this log and provide the number of and last timestamp indicating usage of the deprecated feature, along with the entirety of that log entry.

Each deprecated feature identifier can easily be searched for in Puppet Labs documentation, Jira tickets, and search engines to help determine how a user may address the issue prior to upgrades. After an upgrade where a deprecated feature is removed, the identifier can be displayed directly to a user in addition to the log, and any interactive upgrade can review the recent logs (i.e. 24 or 48 hours) and highlight features removed in the the last MAJOR or MINOR update.

It is understood that newer versions that do not support a feature will also no longer be able to detect the deprecated feature and provide accurate logging of the missing feature that is causing the fault. By separating out the deprecated messages into a separate log and providing a simple tool to search the logs, the user is empowered to easily find the use of the deprecated features and can correlate the IDs with release notes and such as well as the time of upgrades.

Rob Nelson
rnel...@gmail.com

--
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/CAC76iT90BqJTQHxga8nzTHTLoyV%3DjpLJ5BOOgDOjXHcN9dpiMw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Erik Dalén

[R.I.Pienaar]

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

+1

The deprecation log is a great idea if we resign to the fact that Puppet Labs (um, Puppet...) is never going to stop breaking things in its addiction to change.  Ansible & Salt - at least so far - are not inflicting this particular kind of pain on their users, and Puppet should charge ahead doing things the way it has always done at its own peril.  (I get it that Ansible & Salt get to learn from the early mistakes of Puppet, and that's the burden of being the trail blazer, but people won't choose Puppet just because they're nice people.)

At a recent debate I attended in Sydney (Puppet vs Chef vs Ansible vs Salt) I noted that even one of Puppet's most loyal defenders was bemoaning the switch to Clojure, as if Puppet wasn't difficult enough already without switching to a functional programming language in parts of the code base.

Not really sure I follow most of this 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

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. 

Of the large sites I'm aware of I'm not aware of any in my city where there are plans to upgrade to Puppet 4 yet.  Sadly, I know of far too many where there are plans to migrate to Ansible or Salt, or even Chef (Chef's never been big in Sydney).  Meanwhile Puppet's saying Puppet 3 is EOL this year.  Well I think if Puppet 5 is planned for any time sooner than 5 or 6 years away from now, Puppet must have some kind of death wish.

Not that anyone will listen to me, but are so many things that could be improved without planning breaking changes and feature deprecations.

What can be improved?  Well many of the supported Puppet modules.  I recall seeing in a recent OpenStack report, the Firewall module cited as one of Puppet's leading edges.  What wasn't mentioned is all the bugs in it.  How about a major version bump on that one that fixes all the bugs and design issues?

Gosh, I can only imagine if Puppet would turn its attention away from breaking things in Puppet 5, to filling in all the gaps in the Puppet Forge, Puppet's usability could improve dramatically.

Beaker version 3 would be nice too.  It needs to be significantly rewritten, documented far better than it is.

--
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/2c58aaad-d76b-4bb1-b9d1-7457a119723b%40googlegroups.com.

[Alex Harvey]

On Sunday, April 10, 2016 at 3:59:21 AM UTC+10, R.I. Pienaar wrote:

My apologies; I deleted my two posts; I am frustrated after losing the fight to Ansible after fighting for 2 years where I am.  I don't mean to hijack this thread, support Rob's suggestion, and perhaps should write to someone offline.

-alex 

[R.I.Pienaar]

----- Original Message -----
> From: "Alex Harvey" <alexh...@gmail.com>
> To: "puppet-dev" <puppe...@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.

[Eric Sorenson]

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

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.

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. 

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). I'm definitely sympathetic to the viewpoint that the ripple effects since Puppet 4 landed last April have sacrificed the latter. Ironically, in order to cause fewer major-version bumps, we bundled three loci of change together that cumulatively make for a very large barrier to upgraders:

- the language: as RI points out, people who kept current on the changes and deprecations through the 3.x series had a pretty minor lift to get to the Puppet 4.x language. But there's a perverse disincentive that I don't think we really anticipated, where the removals around node inheritance, import, and dynamic scope meant people who'd invested a lot in their Puppet infrastructure when those patterns were au courant in the 2.6 and 2.7 timeframe suddenly faced having to restructure a ton of code which had previously been working fine. You're absolutely right that unless there are substantive benefits for going through that effort, it's only rational for someone to look at non-Puppet solutions for the problem.

- the packaging: looking back to the 2.6 and 2.7 era, the main way people obtained Puppet was through their distribution. Over time, Puppet's immediate dependencies widened to include things like hiera and the costs of supporting distribution-specific Ruby variants exploded, so we consolidated on the all-in-one packaging style and unified the agent side across OSS and PE. This has a ton of benefits (as someone who had to hand-build a patched Ruby to get a fix for the pthread thing I would appreciate someone else having done that for me) but means that people both have to change their adoption pattern and migrate existing hosts, which again has some cost.

- the network stack: while it is possible to run a Puppet 4-based master under Passenger, it's not where our tech roadmap is taking us and we do not make it easy for people to do it themselves. This is probably where the clojure angst you were relaying came in; we've had clojure in our stack since 2012 and nobody got too worked up about it, perhaps because PuppetDB was both opt-in and self-contained. The puppet-server is neither of those things so, again, there's some cost that comes at a point in the stack that is a main point of interaction for people running puppet infrastructure. One cheerleading note on the benefits here: I would encourage people experiencing performance pinch on their masters to try out the latest versions, as our internal scale testing and reports from the field have shown pretty shockingly awesome compile time and concurrency improvements...

​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 :-)

Joking aside, the point is well taken. Until a couple of months ago we felt like the "organic" upgrade rate was pretty tolerable. But I definitely have a sense of urgency about not simply pushing as many people over the line as possible, but identifying and mitigating the causes of upgrade pain more generally. We're not going to stop the pace of change in the industry to let everyone catch up; there will be a Puppet 5 (and 6 and 7) at some point; but clearly we need to take care of people who are successful with Puppet today and make it easy for them to stay current without spending a ton of time managing their management infrastructure.

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

[Thomas Gelf]

I feel a little bit guilty, as my short comment somehow started this
thread. But as the discussion seems to move to a good direction, let me
jump in :)

Am 10.04.2016 um 18:51 schrieb R.I.Pienaar:
>> I guess what this shows is that even when changes don't appear to be

>> user-impacting, they are. [...] 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.

This. Those being "skeptic" (to use a friendly word) felt proven right
with the initial Puppet Server versions and even those who knew about
JMX and it's power had a pretty hard time to figure out what went wrong.

Puppet introduced a complete new stack that asked for much more
resources. This stack had a higher potential to cause trouble. They
tried to hide the possibilities to monitor and diagnose that stack from
not PE-customers.

So, tell me: why should an Open Source user have moved to Puppet Server?
He didn't, and if you ask me, he was right. But the longer he waits, the
more changes he'll have to worry about. The more the Upgrade will hurt him.

AIO packaging doesn't really help here, as they feel to have no chance
to do what they would call a smooth migration.

>>> 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".

You're exaggerating a little bit I guess. Sure, I hear similar
statements. And yes, even from pretty skilled long-time Puppet users. If
someone already using Puppet in a serious way believes that writing YAML
files for Ansible is the way to go... well, let him go. Still, it's
scaring to be presented stats showing more interest in the latter than
in Puppet at well-established large configuration management events.

>> 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.

That's an unfair one. But I immediately believe you that there are
people stick with "import" unwilling to move forward and complaining
about change.

> 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.

What if we use containments as an example instead? import is dead, but
include, require and contain are still alive. Ask someone who "does
Puppet for a while" to explain them to a newbie in an understandable way.

> 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.

You shouldn't compare you to the average Puppet user ;-) They sit in
front of an amount of Puppet code, most of it not written by themselves.
Migrate to Puppet 4? Even pretty skilled people I sometimes work with
are in trouble. Their migration to Puppet 3 happened not very long time
ago, small part of their infrastructure is still running in the "older
world". They invest time, write tests, all changes are pushed through
Jenkins, r10k-related Puppetfile commits happen every few minutes. And
still: they fear Puppet 4.

In one concrete example upgrading would mean to upgrade PuppetDB. Their
PuppetDB is an older version, as they have had some trouble once they
tried last. And then it was left as is. We all know, the longer you
wait, the harder it gets. They've built quite some tooling around Puppet
and PuppetDB. Even more things that could break. Today upgrading Puppet
doesn't mean to just run tests with a new parser and then upgrade your
webservers. It's more and more an All In One game.

And what curiously scares people at most: "Puppet 4? Well, nice, Data
types and so. But you know, no time to dig deeper into this type thing
right now. And all our modules from the forge... who knows what would
break."

They are partially wrong, some of their concerns are without substance,
but absolutely understandable. Skilled people. Others are struggling
much, much more. You have to distinct between "startups" who often run a
single web application based on the usual stack in slight variants and
people sitting in large organizations forced to run an insane amount of
completely different legacy applications.

> [...] 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.

Ack :)

>> 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?

I'm with you on this. Yet, they dropped HP-UX ;) Jokes apart, the
problem is not the support for distributions but the effort you have to
invest to keep on-track without being lost with just one of them.

>> 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.

I'm somewhere in between. Feedback from Puppet enthusiasts is vital.
Getting feedback from the frustrated ones is hard. Sometimes it is
there, but not heard as not direct enough. Some grumbling, a sarcastic
response, a joke with too much truth inside. Sometimes it is smashed
down, see some past AIO threads.

> There's a often quoted stat that 80ish % of large companies DO NOT EVEN USE
> ANY KIND OF CM.

And they know, so they hire one single Puppet guy. They lock him in a
room and tell him to do automation. All the others stopped blaming "the
network" for everything but right now stop Puppet first before doing any
farther investigation when something breaks :D

> 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.

Sure, they have the money. They also have applications running without
anyone touching them since ten and more years, of course absolutely
vital to them. Sometimes you encounter things you wouldn't even touch
for A LOT of money :p

> 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.

Yes and no. Microsoft managed it to create a world for people doing
manual work. Automation people moved along. Those where the skilled
ones. Microsoft did a very good work throughout their whole stack during
the last years. Many people didn't notice how many awesome things they
created. Neither those who left long time ago, nor many Windows admins,
as those changes where not built for them. Now MS is struggling hard to
attract the automation people. You know, that small minority they didn't
care for a long time...

> 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 have to deal with people feeding mainframes, I like them. You might
wonder, but they are also writing Puppet manifests and feed their Icinga
monitoring through exported resources. That's how they also get their
mainframe jobs monitored. So, do not underestimate them.

They make part of the 80%. They have no trouble to debug the old Puppet
world. What's most troublesome to them are dependencies and exported
resources. Dependencies can always somehow be solved, sometimes with
pretty ugly hacks. Debugging PuppetDB is a hard task. And even if Puppet
Server is a different beast as there is "no data you might want to look
at", for them it's one more step in that "JAVA direction". Some of those
80% are used to run Java applications. But they have no insight, no JMX.
They automatically restart them when they run out of memory :p

> 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.

Orchestration! I did a lot of funny projects with MCollective. Steep
learning curve for many, but once they lost their fear it started making
fun to them. You know, it often was their first message queue. Nice
product. Had only one customer that fully understood it. The others got
some tooling and used it to do a few things on demand. Like disabling
all Puppet Agents once they realized one of their changes started to
kill their systems one by one ;)

Nobody deprecated MCollective, but to them it was part of the Puppet
ecosystem. They invested time, built their tools around it or paid
others to build those tools. It feels like a pretty dead product these
days. So, this proves both of you right. It is still there, still
somehow supported. But they have been indirectly told that they are
riding a dead horse.

> 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).

Luckily those 80% you named do not get very nervous about those trends.
Try to tell them about the twelve factors all their applications should
respect to make a good candidate for Docker...

I love containers, I'm running containerized applications in production
since 15 years right now, started with patched Linux kernels. But
honestly, I hate Docker. More for what people tend to use it for, than
for the product itself. Docker has it's use cases, but people tend to
use it as their new JAR file. You'll not get rid of CM this way. You
just moved your problems to a container.

> 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.

And they are doing it the right way. Still, I guess many of the "80%"
you mentioned before will still be there when 80% of those shiny new
startups no longer exist. I know who you mean when you talk about
"change averse friends". But please do not forget that many brave people
working for those 80% are pushing Puppet projects forward.

I guess you know how this works there. They get some dedicated time,
they get their budget, they have to ship their project. And then they
have to move on getting other things done. As during the "Puppet
project" their team still has a ton of other things to do, introducing
Puppet could easily take two years. Not to install the product. To train
people, to prepare changes, build and run test environments. Even the
paperwork to order new servers could take several months. And once they
are done and feel ready to roll it out, they start with an already
completely outdated product, let's call it Puppet 2.6.

After some time they start a migration project to Puppet 3. Guess what
happens next. So by now, for several years they spent most of their time
for their CM tool, instead of the CM tool saving their time. It's not
Puppet's fault. Puppet is an amazing company, doing a very good job in
moving a strong product forward. But they deluded people. Quite a bit.
Calling all of them "change averse" is not fair.

> 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.

Yes and no. Those 80% have an orchestrator that works fine to them. They
use to call it SSH. It can be used the wrong way, but it scales well
enough for the few thousand boxes their teams usually run. You're right,
Puppet's orchestration ideas do not convince me either. But even if they
would completely ignore Kubernetes the market for legacy CM for the next
20 years will be large enough to feed their company.

What I see more dangerous is that Puppet tries to sail every new hype
instead of sharpening their own vision. I know there is some pressure to
do so, as you have to be "cool" in this market today. Times were better
when CM wasn't cool at all.

> 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.

And the mainframes are still there. As they have LPAR since a very long
time they might not share our excitement about containers. Their
workloads are predictable, so autoscaling is mostly not a requirement.
If they need to scale, they often can - it's just a matter of money. Try
to sell them a tool offering service autodiscovery, and nothing built in
what they would recognize as a security feature. Good luck :)

> 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.

My suggestion would be to try harder to find Puppet's own identity. They
aren't big enough to do everything, but trying to do so. It's amazing
how much they are able to ship, but I hardly doubt there are enough
resources to be brilliant in every single discipline. It's hard to make
startups and dinosaurs happy with the same product. Telling one of both
to behave more like the others might not work. And there are a lot more
groups Puppet tries to target.

One last very important factor to the mentioned frustration is the fact
that Puppet is an Open Source product. People over here in Europe see
this stricter than they might in the US. If you say "...and it has an
Enterprise version", 99% of the time "Oh, so it isn't really open?" is
the reaction you get. And for many it's not about the cost. Many large
rich companies use a lot of Open Source software. Not because it is
cheaper, but because it doesn't lock them in.

Until now it wasn't hard to argument against this, Puppet 3 was a
wonderful open source product. It was also very easy to extend and to
fix if something went wrong. This changed with the new stack. I know
people paying PE licenses while running Foreman. They pay to feel on the
safe side with Solaris and AIX support. But they refuse to run a
frontend that's not "open", even if they paid for it.

Nonetheless, I'm a happy Puppet user and still defending it. Even whilst
sadly disagreeing with more and more of it's strategic decisions.

Best,
Thomas

[James Turnbull]

> One last very important factor to the mentioned frustration is the fact
> that Puppet is an Open Source product. People over here in Europe see
> this stricter than they might in the US. If you say "...and it has an
> Enterprise version", 99% of the time "Oh, so it isn't really open?" is
> the reaction you get. And for many it's not about the cost. Many large
> rich companies use a lot of Open Source software. Not because it is
> cheaper, but because it doesn't lock them in.

(disclosure - I no longer work at Puppet although I remain a shareholder)

Puppet is a business.

Who contributes to Puppet open source? There have been a handful of key
contributors (Hi Brice!) who haven't been paid by (Puppet|Reductive)
Labs. That amazing open source product you use is paid for by selling
the "evil" Enterprise version and prior to that by professional services
and prior to that by Luke consulting and doing custom development.

They'll always be a tension between what's open source and what's not,
there'll always be different customers/users for both products but
without that tension and those customers there wouldn't be an open
source product to use at all.

Kind Regards

James Turnbull

--
* The Art of Monitoring (https://artofmonitoring.com)
* The Docker Book (https://dockerbook.com)
* The LogStash Book (https://logstashbook.com)
* Pro Puppet (http://tinyurl.com/ppuppet2 )
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

[Thomas Gelf]

Hi Eric!

Am 10.04.2016 um 21:16 schrieb Eric Sorenson:
> On Apr 10, 2016, at 2:05 AM, Alex Harvey <alexh...@gmail.com

> <mailto:alexh...@gmail.com>> wrote:
>
> [...] 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.
>
> 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 [...] we bundled three loci of change together that

> cumulatively make for a very large barrier to upgraders:
>

> - the language: [...]

While I definitively know that they are still there, less and less
people (at least those who I met and know) are running 0.2x or 2.x. They
invested a lot of time and are happy 3.x users right now. And realized,
that they are on an old version once again. And you nailed it, the
language alone is not the problem at all. Puppet 4 has a lot of new
features, but for a migration you do not even have to learn about most
of them. Still, there are small differences that could hurt. They are
well explained, but they are not always easy to find in your modules.

The bigger problem to many is that basically the whole stack changed.
For many, Puppet was the reason to learn Ruby. I personally loved it to
teach the "Extending Puppet using Ruby" classes, even if we didn't sell
many of them. They would still be requested, by the way ;) I stopped
doing trainings once that class got discontinued.

But let's get back on topic. They invested time, learned something new,
and right Puppet started to do what they want. And they learn that
Puppet would prefer to fade out the language they learned only to get
more out of Puppet. We all know, this won't happen very soon - but
that's the message they got. And they feel a little bit lost, as there
might arrive something new, but it is still very unclear what that might
look like. Just wanted to mention this, because this also somehow makes
part of the "language".

So, move to the new "Java/Clojure" stack? Loosing all the insights you
have right now? While knowing that more changes are around the corner?
Many might decide to wait a little bit longer.

> - the packaging: [...]

You might underestimate this, this is a big problem. IMO that's even
more a problem than the whole Java/Clojure thing. First, to many people
running Open Source puppet this feels like a lock in. If you try to run
at least parts of the server stack separate, you have a lot of fun. And
while Puppet is doing a very good job in shipping (security) upgrades
all this feels not natural to many Linux admins. OpenSSL, Ruby, Java,
all this from a single vendor in a separate directory? What if there is
heartbleed, you must immediately upgrade but for whatever reason your
Puppet is some versions behind?

I immediately believe you that you also would care about those older
versions. But that's a matter of trust. Puppetlabs OSS package
repositories tend to be deprecated early, why should someone not running
PE put any trust in whether all this would work for him with OSS AIO in
a heartbleed-like scenario?

Everybody understands it when you say "The Puppet master needs at least
PostgreSQL 9.1 and Ruby 1.9.3", just to pick some fictional numbers.
Supporting the Ruby agent on distros running Ruby 1.8.7 and OpenSSL
0.9.x for sure makes no fun, but it would have absolutely been possible,
wouldn't it? Replacing it with the C++ one once available. AIO is
definitively one of the reasons many people fear Puppet 4. I personally
could live with git clone'ing Puppet Agent and Master, that's more then
half the way to get it installed. But I guess that wouldn't convince many :D

> - the network stack: while it is possible to run a Puppet 4-based master
> under Passenger, it's not where our tech roadmap is taking us and we do
> not make it easy for people to do it themselves.

And many do not see what should be so wrong with running a Ruby-based
master under Passenger, Unicorn or whatever.

> This is probably where
> the clojure angst you were relaying came in; we've had clojure in our
> stack since 2012 and nobody got too worked up about it, perhaps because
> PuppetDB was both opt-in and self-contained.

That's right, PuppetDB has always been seen as a separate component.
Often running on dedicated servers, upgraded separately. Usually nobody
but the Puppet master needs to directly talk to it, so in case there is
a security issue with any of it's dependencies and you fear a fast
upgrade you can still lock it down with some firewall rules.

> The puppet-server is neither of those things so, again, there's some
> cost that comes at a point in the stack that is a main point of
> interaction for people running puppet infrastructure.

And when there is some cost people tend to ask for the benefits...

> One cheerleading note on the benefits here: I would encourage people
> experiencing performance pinch on their masters to try out the latest
> versions, as our internal scale testing and reports from the field have
> shown pretty shockingly awesome compile time and concurrency improvements...

All this is pretty cool, and while initial Puppet Server versions
performed badly I immediately believe you that this changed a lot. But
hey, where is the benefit for those happily running a Puppet master
without performance issues? And not worrying if they have such as they
know how to scale it?

PuppetDB is hard to scale, but adding compile masters has never been an
issue, at least not since a very long time. I've seen Foreman breaking
under reporting bursts while a single PuppetDB 1.6(!) instance serving 3
compile masters kept happily running. So, again: where is the benefit
with all this for a Puppet setup serving several hundred to a few
thousand nodes? Those with tens of thousands of nodes will not ask that
question I guess. And those with that many containers probably to not
install Puppet AIO in all of them.

> 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 :-)

Once you found them, give them some alcohol and listen - this usually
helps ;) Yet, finding them could be tricky :p

> Joking aside, the point is well taken. Until a couple of months ago we
> felt like the "organic" upgrade rate was pretty tolerable. But I
> definitely have a sense of urgency about not simply pushing as many
> people over the line as possible, but identifying and mitigating the
> causes of upgrade pain more generally. We're not going to stop the pace
> of change in the industry to let everyone catch up; there will be a
> Puppet 5 (and 6 and 7) at some point; but clearly we need to take care
> of people who are successful with Puppet today and make it easy for them
> to stay current without spending a ton of time managing their management
> infrastructure.

I'm not to be found on Facebook or Twitter or anything similar, but I
would immediately like and retweet this many many times ;-) Thanks a lot
for listening!

Cheers,
Thomas

[Thomas Gelf]

Am 11.04.2016 um 00:47 schrieb James Turnbull:
>> One last very important factor to the mentioned frustration is the fact
>> that Puppet is an Open Source product. People over here in Europe see
>> this stricter than they might in the US. If you say "...and it has an
>> Enterprise version", 99% of the time "Oh, so it isn't really open?" is
>> the reaction you get. And for many it's not about the cost. Many large
>> rich companies use a lot of Open Source software. Not because it is
>> cheaper, but because it doesn't lock them in.
>
> (disclosure - I no longer work at Puppet although I remain a shareholder)
>
> Puppet is a business.

No doubt. I had above conversation with a customer who I convinced to by
PE the very same day. I explained it's advantages, they decided to buy
it. But not before being assured that there is no hidden lock in. They
had no problem with the money at all. It was a small national bank of a
country not being part of the Euro, so they are printing their money
themselves. But they wanted to make sure that Puppet was serious about
being "open". By that time they have already been long time Puppet
users. You know, when "import" was still a thing ;)

> Who contributes to Puppet open source? There have been a handful of key
> contributors (Hi Brice!) who haven't been paid by (Puppet|Reductive)
> Labs. That amazing open source product you use is paid for by selling
> the "evil" Enterprise version and prior to that by professional services
> and prior to that by Luke consulting and doing custom development.

I know, I work for an Open Source company. The "community" is VERY
demanding. But who writes most of the code? We have to mostly do so
ourselves. We get quite some contributions, some very good ones, and
many others would have caused less work if we had done them by ourselves.

We live from consulting, customizations, support and professional
services. You'll not get rich that way. Our business model doesn't
scale. But hey, it makes fun, we earn enough for a living, I work for a
healthy company, our software is being used all over the world. Our
advantage: we are not driven by Venture Capital, we are allowed to grow
slowly.

Releasing an Open Source software is nothing Luke has been forced to do.
And no, there is nothing evil with an Enterprise version.

> They'll always be a tension between what's open source and what's not,
> there'll always be different customers/users for both products but
> without that tension and those customers there wouldn't be an open
> source product to use at all.

That's not an issue at all. There should just be some clear line
explaining where Open Source ends and Enterprise starts. And
"Enterprise" shouldn't make life harder for people. I initially had so
much pain with the customer I mentioned above. They wanted to have a
redundant installation, and Puppet rolled out by Puppet. No issue at all
I thought, I did this many times before with OSS Puppet. Then I digged
deeper into the first Puppet Enterprise installer and wondered how I
could ever get this done in an idem-potent upgrade-safe way...

Btw, once there was "Live Management" a thing I tried to use that
feature as a USP to sell PE. Honestly, I never had a serious use case
for it. Some manager liked it, didn't work for tech people. Seen from
today, I'm happy that it didn't work, as I would have felt very bad
being forced to tell them that that promoted feature was going to be
deprecated.

What still works well is using "Professional AIX/Solaris support" as a
selling argument. The new frontend is very cool, but that didn't really
work as a good argument for PE. It's hard to explain that one has to pay
a license for every node if he wants to use a specific frontend on the
master. Eventually apart from node-based licensing trying to find
products easy to sell as helpful additions to Open Source environments
could work quite well for Puppet.

But back to why I wrote the above. I remember that Puppetlabs stated
that Puppet will always be open. Many moves in the past and some
announcements felt like this might change a little bit. Sure, it will
stay open. But it could change in a way making it hard to use Puppet
without buying PE. Someone who comes from a Ruby-based Puppet world
already feels locked out by the Server being Java/Clojure, Facter a
binary and everything AIO-packaged. That's what they only know from
non-OSS vendors. Non of this is a problem on it's own, but together...
one might get mixed feelings.

I guess you misread my above statement, or my English was too bad to
express myself clearly enough. I mentioned this OSS thing just by the
end, after many other statements. Not because I do not like Enterprise
versions. But because I see that there is quite some uncertainty amongst
Puppet users regarding the direction OSS Puppet might take. And in my
believes this is absolutely related to what Alex brought up. Unrequited
love, feeling betrayed, not sure how to name it.

Cheers,
Thomas

[Rob Nelson]

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

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.

I think it's a legitimate concern. That's why I brought this up. Being surprised by some missing or changed functionality on an upgrade makes everyone less likely to upgrade. That's what I want to address. With that in mind, my proposal remains to provide deprecated features an ID, log them to a separate log, and/or provide tools and methods to present these deprecation messages to the user front and center on demand.

Some greater context around this may help describe my concern and goals, as it really goes beyond just Puppet. Like many people, I and my employer use products from dozens of vendors and upgrades are, generally speaking, not fun. To pick on another vendor, going from ASA v8.2 to v8.3 or higher was fraught with a lot of danger. And that was just a minor release!

Keeping track of where each vendor logs these messages - if they log them anywhere at all, rather than just place them in the release notes - is tiresome. I'd love to get ALL my vendors to create a central deprecation log so I could review it before upgrades and compare it against the release notes to see what will break. This would, in my opinion, be a competitive advantage for any vendor that did this. I'd be far more likely to use them over a competitor who ambushes me on every upgrade.

We spoke of openness earlier, and Puppet is the only vendor I work with that is open enough that we might be able to get such a feature. With a little refinement past the initial implemention, I could then hold this up as an example of how to do things for my other vendors.

So, if we can drag this discussion back around (split off from the other thread), are there any other suggestions I should include in the RFE ticket?

Rob Nelson
rnel...@gmail.com

 

[Rob Nelson]

I created https://tickets.puppetlabs.com/browse/PUP-6169 for those who want to watch/vote/comment further. Thanks everyone!

Rob Nelson
rnel...@gmail.com