On 04/11/2016 07:38 PM, R.I.Pienaar wrote:
On 11 Apr 2016, at 17:45, Eric Shamow <[email protected]
<mailto:[email protected]>> wrote:
On April 11, 2016 at 4:08:51 AM, R.I.Pienaar ([email protected]
<mailto:[email protected]>) wrote:
----- Original Message -----
> From: "Thomas Gelf" <[email protected] <mailto:[email protected]>>
> To: "puppet-dev" <[email protected]
<mailto:[email protected]>>
> Sent: Monday, 11 April, 2016 03:30:58
> Subject: [Puppet-dev] Re: The Future of Puppet [Was: Deprecation logs]
> Am 11.04.2016 um 03:01 schrieb Rob Nelson:
>> Of course there's lock in. You can't click a button and go from
Puppet
>> OSS to Chef OSS; [...]
>> Is their concern about being able to contribute to it or even fork? I
>> suspect that's what most lock in concerns are really based on.
>
> It's about going from Puppet OSS to PE, forth and and back. No problem
> with loosing the GUI or special add-ons. But the core functionality of
> your CM tool, that's what they want to be free software.
>
Eric asked so here it is, this is my feedback with a open source
user hat
on. Echoing much what was said. I hope others send in their story.
I don't often contribute on this list but this discussion raised so many
points I feel really uncomfortable about at the moment, I may as well
add my thoughts.
I started with puppet 0.24 or something and since then I almost
exclusively work on projects where I help to build the puppet
infrastructure and the tooling/workflow around it. I have not a single
customer right now who adopted puppet 4.0 for various reasons. For
someone who basically works daily with your tool I feel strangely
disconnected from the resent developments and there are probably various
reasons for this. I will try to explain some of them here and I hope you
don't see this as just another rant but accept it as feedback from a
user of your software.
As you can tell from the versions we started out we are already familiar
with upgrading the puppet stack, and so far there was always a good
reason to do it. Yes sometimes there was some pain involved but there
was always a good reason to make the investment and it was relatively
easy to convince the people who actually pay for it why we had to do it.
This time around it just seams very different..
* PuppetDB *
When PuppetDB first came out we looked at it and tried to figure out
what the reason was for this software and how we could deploy it to our
puppet stack. We immediately discovered that there was a problem with
the node decommissioning process and exported resources, which was the
only reason we used stored_config in the first place.
PuppetDB did not add any value, it did not replace the functionality we
needed, it was some very different stack no one had any idea about how
to even debug the thing, so a bug was filed and we continued to use MySQL.
Now we are in the situation where if you want to upgrade to puppet 4 you
have to migrate your stored_config to PuppetDB. Since we did not already
adopt it and we want to minimize the risk of having to upgrade puppet
and migrate stored_config at the same time, the situation is even worse,
since we would have to upgrade to an old version of PuppetDB first (with
puppet 3 support), then upgrade Puppet and then upgrade PuppetDB again.
There may be distributions where this is easy. But there are customers
who don't use RHEL and to even build PuppetDB from behind a corporate
firewall is a serious nightmare. I am not a Java guy, and maybe that's
nothing special in those realms, but I had to even fiddle with some
export restricted encryption jar stuff to make it work which made me
check the date to make sure I did not accidentally travel back in time.
For something that still does not add any value for us that's a lot of
work which is difficult to explain to the people who actually pay this
work. If you make the decision to make this investment you are locked on
puppet 3, which wasn't a problem until it was suddenly announced to be
EOL at the end of this year...
* Puppet 4 *
It's not like Puppet 4 has some serious killer feature which justifies
the investment to migrate right now. I am sure it is a great product and
it has a lot of improvements. The problems we are currently facing has
nothing to do with the puppet language, it has to do with the
deployment, with code quality and orchestration in a world where
multi-node setups just exploded.
There was one comment in this thread from puppet(labs) which hinted at
that there isn't a lot of contribution to the open source puppet from
the community and that puppet(labs) has to do all the work. Well maybe,
but there is A LOT of tooling around puppet which actually adds a lot of
value which comes from the community and without it there would not be a
meaningful way to deploy code (r10k, librarian-puppet), write tests
(puppet-rspec*), refactor code (puppet-catalog-diff), manage secrets
(trocla) and serve your custom code as modules (puppet-forge-server).
What I see is a lot of evolution on the puppet stacks in various
companies, but at the moment it has nothing to do with the language, the
focus is simply elsewhere. The question goes like this:
Why should I be currently interested to check 100 forge modules and 200
internal modules for puppet 4 compatibility and maybe even fork some of
the forge modules (because the maintainer vanished or whatever) when
there is no immediate value and maybe even the risk of loosing some of
the value the community tooling adds. How can I justify this?
* The future *
I did not even touch puppetserver and all the other new stuff in this
post, since this stuff is even further away.
With the puppet 3 EOL almost at the doorstep, the future looks rather
bleak. I seriously have no idea how I can convince a customer to invest
months into code updating without some value coming from it. I know
there is always a maintenance cost with code, but this seams rather high
and it does not look like it get's cheaper post puppet 4.
And maybe you noticed, it has absolutely nothing to do with PE or OS puppet.
Greetings
Andreas
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/570E07D5.1040902%40puzzle.ch.
For more options, visit https://groups.google.com/d/optout.
