Re: The Future of Puppet [Was: Deprecation logs]

[Rob Nelson]

Lots of great discussion this weekend! I've changed the subject, since we've changed our subject and this may help with future searches on the ML archives.

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

Of course there's lock in. You can't click a button and go from Puppet OSS to Chef OSS; it's no different with enterprise versions. I'm sorry, but I find this to be a really awkward concern to face. Even when you talk about something known for lock-in, like Oracle or AWS, it's about getting the data out. Some very well publicized stories about companies migrating away from both and it's never easy. Lock in is perhaps the most specious concern people have with software.
 

themselves. But they wanted to make sure that Puppet was serious about
being "open". By that time they have already been long time Puppet

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. 

 

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.

Agreed. This looked great on the surface. However, every action was owned by the live management user which essentially made it unusable in any regulated environment. I hope they find a way to fix that and bring it back, but until then, it's absolutely best that it is not present at all.

 

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.

This is curious to me. Most I hear are happy to not have to worry about passenger/apache/nginx changes and just let the vendor worry about that. And ruby versions? That's a circle of hell on its own that no-one wants to dive into (someone earlier mentioned getting things to work with ruby 1.8.7, but on those distros its possible to lack support for SNI and TLS 1.2, which are significant problems in 2016). I live mostly on the Ops side, however, so may color my experiences far differently than others.

 

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.

Uncertainty is bad. But I do sympathize with Eric - how to alleviate that concern among users who don't engage with Puppet in the dozen different ways available to them already?

 

Rob Nelson
rnel...@gmail.com

[Thomas Gelf]

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.

> 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.
>
> This is curious to me. Most I hear are happy to not have to worry about
> passenger/apache/nginx changes and just let the vendor worry about that.

Could be a cultural thing. Ops people I met usually want to understand
and control the stack they run. And CM is a key component to your
infrastructure. I guess many companies in the US would happily run their
Puppet master in the cloud. An absolute no-go for most European ones as
of today. Well, I've met a single one where one department wanted to do
so to circumvent policies. They hated their Ops people but were not
allowed to run their own systems :D

> And ruby versions? That's a circle of hell on its own that no-one wants
> to dive into (someone earlier mentioned getting things to work with ruby
> 1.8.7, but on those distros its possible to lack support for SNI and TLS
> 1.2, which are significant problems in 2016). I live mostly on the Ops
> side, however, so may color my experiences far differently than others.

Well... nobody wants Ruby 1.8.7, but it's there. One might decide to use
SCL packages. Backports, whatever. But it's a package shipped by your
distribution. Tell people that it is not supported on the master, no
problem. That they might face some specific issues, fine. But shipping
AIO instead? You're right, that's for people that "let the vendor
worry". They are also fine with software shipped in VM images or Docker
containers.

> Uncertainty is bad. But I do sympathize with Eric - how to alleviate
> that concern among users who don't engage with Puppet in the dozen
> different ways available to them already?

Even if all of them would listen I doubt a single announcement could
solve this :p

Cheers,
Thomas

[R.I.Pienaar]

----- Original Message -----
> From: "Thomas Gelf" <tho...@gelf.net>
> To: "puppet-dev" <puppe...@googlegroups.com>
> 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.

Thanks for the replies, the level of detail and obvious care and emotion that
goes into these mails have been good to see and I am sure valuable to everyone.
I hoped my mail would spark a wider conversation hopefully involving some
Puppet people as well as some of the community - even those who don’t often
engage and it looks like we’re off to a good start.

While my earlier mail was most certainly squarely to the one side of the coin
as pointed out there is another. My earlier mail shows how a company in
Puppets position might think, I do not know if I am wrong or not as I have no
insights into the internal convos but my gut feel is I am not far off. But I
specifically wanted to state that side first because it’s important to
understand as it frames expectations one should hold.

The other side of the coin for me is that of a open source user and I think the
outlook is particularly dire. Excuse the following wall of text but we have to
talk about how we feel and what the current reality means to us as a class of
user.

Open Source users often see the existence of some open source tool as a implied
contract that it will always be so, and their adoption of it is based on that
perception. This is encoded in the very licences we hold deer and when that
inevitably turns out not to be realistic business model the companies involved
will do what they can to survive. Inevitably this ends up breaking the
‘implied contract’ the open source user rightly or wrongly felt they had - cue
much anguish and resentment.

The company will then go on to explain themselves and make commitments - we
will keep the core product open but innovate on paid for enterprise features
like RBAC and very featurefull GUIs. We will not work to exclude other makers
of tools and your home grown tooling, we will make the extension points open
and APIs open for others to innovate on.

I don’t have the actual quote to hand as I am sat on a plane but this seems to
me more or less the story we were told when PE became a thing and that seemed
good and a model worth supporting. After all what would be open source is not
unlike most other open source and we are not averse to applying some duct tape
and glue to make things work.

Fast forward to now and the situation is not like this at all. Today we have
the puppetserver product touted as the only way forward and not only does it
have PE only APIs its core operability features are PE only too. Performance
metrics and atomic deploys. No longer is it a matter of if you put in the
effort and build the tooling you can use the Open Source product but we will
sell world class tooling. We’re now in a world where the ability to monitor
the product and gain the insight you need to scale it requires you to adopt a
per node based payment model. Being able to monitor a service only when you
pay for it. I am not sure I've seen a worse model for the 'free' users.

Now tools like Foreman cannot compete because they cannot monitor the master
and they cannot have atomic deploys. Who knows whats future PE only APIs will
come? I'd bet things around file serving, catalog life cycle management etc.

Now similarly open source users cannot compete because they cannot gain the
insights they need to scale this java blackbox, even if they invest the time to
learn the JVM, the software in the JVM is actively resisting their efforts of
gaining operational insight. Their own tooling cannot compete against PE
because some APIs are PE only.

Personally as a open source user I use ‘apply’ - I decided during my P4
migration to look again at using a master - puppetserver - and was all set to
move machines onto it that weekend when the metrics blog post came out. The
puppetserver VM got immediately deleted. This is not a future direction that
is cooperative or long term tenable for me.

If you’re a open source user you need to look very carefully at the messaging
and feature set and you can really only come to one conclusion and that is that
to Puppet you’re just not a priority. Less than a priority you’re effectively
being locked out and worked against and lack the ability to make a well
monitored CM system if you adopt open source puppet.

I hope the metrics situation will change - there has been other PE-first
features and they came to Open Source so its not unprecedented but in this case
it will pay to wait and see since if these features are not coming to Open
Source then the whole is unusable.

It’s a pendulum that swings, whats the right answer and right balance is not
black and white. It’s a fiendishly difficult business problem and you have to
commend Puppet for even bothering with Open source at all this point so I try
and see the good intentions towards the open source user base. And while I am
quite negative in this mail I do not think they are maliciously working towards
excluding us. Hopefully Puppet realise in these cases the pendulum swung too
far and will correct the course.

Either way, the signal to Open Source users is that you need to really deeply
consider your options post Puppet 3. It’s undeniably a high risk situation. It
might well be the most significant decision you make in the next 5 years of
your infrastructure and of your career.

On the points of migrating to P4 from earlier Puppet. Its a major problem.
Not only did the entire system change - in every respect, every component has
had a major rework and rethink from 2.6 days but the language have also in
effect become a new language. Not surprising for a 10 year old product.

Yes there is some semblance of backward compatibility on the language level.
But there is no doubt that New Puppet is exactly that. It’s a entirely new
product with a backwards translation layer. Ask yourself does just updating to
P4 and running your existing code achieve much? No it doesn’t it means you’re
still running an outdated code.

But getting to the point where you’ve updated Puppet to 4 and are now on a new
set of software but still not rewrote your code to New Puppet is a colossal
task since the world we live in is so resistant to upfront testing and
rollback. And then you’ve still achieved more or less nothing because now you
also have to consider basically rewriting your code to take advantage of the
new features.

Worse before you can even begin to look at refactoring your code you need to
learn an entire new Puppet language and set of technologies and their
environments like the JVM, new deployment locations, new packaging models new
everything - worse ones that resist introspection. All while there is scant
information on new patterns, no new style guides, the supporting system like
rspec-puppet doesn’t support P4. Documentation is lacking or embryonic and so
forth. rspec-puppet especially is a bad situation since many who have invested
in a tested infra will loose the value. Ditto for puppet strings etc.

I hope my blog posts and upcoming talks at conferences help those who do want
to take on this task, but it’s a task much larger than that. Meanwhile other
tools like mcollective are effectively abandonware with no viable alternative.

Feedback I’ve had on some of the modern Puppet code I’ve put out is that it
does not look like Puppet at all. It’s a new thing, literally your foundations
of your 10 story building needs replacing if you wish to move forward. In the
world IT admins live in you’re asking to replace the foundations while keeping
the building standing, a tall order at best. (see
https://github.com/ripienaar/puppet-classifier for modern puppet code)

It’s truly a perfect storm of a fuckup when looked at from a Ops perspective as
an open source user.

So while I made a point of calling out the ‘resistant to change’ user, there
are several version of these.

You have your people who just won’t change - I have no sympathy for them as was
clear.

But you also have those who wish to change and who look critically at the P4
vs < P4 and come to the correct conclusion that this is a high risk multi month
if not multi year project. They correctly deduce that Puppet is now so big
that you need a dedicated team managing the manager. Something many of us just
can’t afford or indeed who wants to spend their days doing nothing but manage
Puppet?

For many just getting Puppet in has been a massive politically charged internal
struggle. It’s a constant battle between forward thinking admins, old style
admins, developers and management who want to instead see features delivered
and not management tools managed.

Having just won the battle, one that was in many cases a battle fought out of
having a deep respect and affinity for the company, its founder and products,
now they find they’re squarely screwed and have to again invest possibly years
and again have the fight with everyone the exact same battles and again have to
budget for years of disruption. While it’s clear the Puppet won’t slow down its
change curve.

They correctly conclude that they WANT to change but cannot afford to. They
also correctly conclude that the task is so big and Puppet moving so fast that
P5 will be around long before they are on P4. And so the cycle will just start
again. Its realistic to think the opportunity cost of continuing with Puppet
is simply to high a price to pay for what it brings when you’re on <P4 today.

Staying is no option as it will be unsupported and we have to consider security
updates and such. Change they have to change, rock and a hard place.

There is not much more frustrating and insulting than a company who puts you in
that position and needless to say if the effort has to be put in anyway they
will look elsewhere. I suspect the paying customer base will approach the
transition similarly. I have no data on this but would be interesting to know
how many old PE users are transitioning to P4 based PE once the older support
cycle ends.

I am deeply sympathetic to these people and it’s sad to say but where we are
today is that they are simply SOL and there is no light at the end of the
tunnel when you can’t even have a hope of gaining deep insight into New Puppet
without paying.

So given a choice to rewrite all my code to P4 I instead came to a hybrid
approach:

* Move my actual things I run into containers - web sites, bind, smtp
servers, etc all in containers. Not puppet managed.
* As machines move to CentOS 7, make them P4.
* When on P4 only manage with Puppet the low hanging fruit like resolvers,
sudo, users, sensu and bacula. Most from the Forge.

Why do it this way? Well my environment is a R&D environment so I enjoy looking
towards new tech and this is the world I want to innovate in but more than that
where my P4 is now it’s doing very little. So little that any competitor in
the CM market can step up and replace P4 for me really quickly as it appears
more and more likely this is an important consideration.

I felt I had no choice but to approach it this way because as a Open Source
user the future is not bright at all - as per my previous mail I am just not a
priority - and I can’t really blame the company for feeling this way.

I’d use PE as I have nothing against it but as this is a R&D network the $3000
licence for my node count I’d need does not seem like a good way to spend my own
pocket money.

I myself am bout 50/50 through my P4 migration and it’s been a daunting task to
say the least - though I am under no time pressures and am taking the time to
gain a deep insight into what P4 is, what motivates its existence and to regain
the deep understanding I had of < P4 and so forth.

I am though a consultant in this space and Puppet is creating a massive
customer base for what I do so it’s not like its wasted effort for me, as was
pointed out, I am not typical though. Given the amount of money out there for
consultants in a world Puppet literally create from nothing - wearing my
consultant hat I’d say keep going as you were. And Puppet does really good
things to support the consultants in their space via partner programs and such.

P4 on it’s own is a brilliant tool brilliantly engineered and the language
innovations are really good. The engineering rigour is orders of magnitude
better than we had before and it really shows in the end result. I have nothing
but positive things to say for P4 and the team that created it.

It’s unfortunate P4 is combined with a supporting eco system that while
innovative, powerful and potentially game changing is making it irrelevant to
me as a class of user since they are more and more approaching things in a way
that locks me out of the future I - and many like me - helped create.

[Eric Shamow]

Hi Arri, it’s been a while :)

I agree with most of your rant until here. While I think the engineering quality of what Puppet is producing is indeed miles ahead of where it was, the product design itself (including language innovations) are core of the problem to me. They aren’t, as best as I can tell, designed with a particular customer in mind - I certainly can’t find the sweet spot customer for whom PE is the right product. For every quality innovation, there are 2-3 seriously breaking changes that not only indicate a lack of understanding of how Puppet is currently managed in the field (what the ecosystem is doing, what typical deployments look like, etc), but also that are likely to lead the new, inexperienced, middle-of-the-road customers PE used to be targeted at down entirely incorrect paths.

The current state of the Classifier and Code Manager are examples of this.

From my own experience, customers are losing confidence that Puppet understands their world. I certainly am no longer certain that it does. Both from the rapid iteration of change in order to add functionality that doesn’t visibly improve their work but mandates frequent refactoring to moves like launching products without support for operating behind proxies, the perception that Puppet is a tool by admins for admins is waning pretty seriously. And most new users, as you note, are embracing the wrong kind of configuration tools specifically to get around it.

-Eric

It’s unfortunate P4 is combined with a supporting eco system that while 
innovative, powerful and potentially game changing is making it irrelevant to 
me as a class of user since they are more and more approaching things in a way 
that locks me out of the future I - and many like me - helped create. 

-- 
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/371534503.181383.1460372927683.JavaMail.zimbra%40devco.net. 
For more options, visit https://groups.google.com/d/optout. 

[Rob Nelson]

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?

Everyone wants one tool to do everything. If you need Ansible because your non-Nexus Cisco gear has no chef/puppet agent, why not just make the switch everywhere? Yeah, you and I think that's a dumb reason, but people do things for (or in spite of) dumb reasons all the time. Short of spending all their time getting agents for every networking device out there, I don't think there's much you can do to stop these kinds of migrations. And do you really want to appeal to people who enjoy ssh for loops? The best you can hope for is some synergy, which seems to happen when people actually understand what their different tools are good for - Puppet for CM and Ansible to Orchestrate it.
 

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. 

I see PL employees on Reddit and SO and other sites all the time, and IRC to boot. But those are sites I'm biased towards. What other sites do you think are important and underserved?

Rob Nelson

[R.I.Pienaar]

To be clear when I say P4 I do mean puppet and not all the rest of PE :)

[Dean Wilson]

On 11 April 2016 at 12:08, R.I.Pienaar <r...@devco.net> wrote:

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

Since you asked so politely.

I have a few main areas of concern, and oddly they are not so much
with the core puppet project. I think most of the work going in to it
is solid and makes the product more durable and offers a certain
amount of extra sophistication with things like the type system.

So, my issues:

AWS: Over the last 5 years I've deployed a -lot- of AWS and spoke to a
lot of people about it and unless they are a large enterprise
forklifting their current environment over or looking to run a few
bits of code at instance time, and just happen to have admins who
already know it, puppet doesn't really enter the equation. I remember
evaluating Puppet support for AWS resources about 4 years ago, finding
it in a very nascent state and then checking in every 6 months or so
and discovering that it's essentially not moved. To ignore such a
large player and platform these days is a massive negative to a lot of
potential users.

A lot of places went with Ansible for this use case and even though
it's not an area puppet can be said to compete in its led to places
dropping the bits of puppet they did use and running local only
ansible on instances at create time. After all why run two config
management tools? In the same time frame Terraform has appeared and is
currently eating the cloud provisioning world. And what's annoying is
that if you use it for a few days it feels so very much like puppet
0.25 did. Its sharing mechanisms are amazingly basic, it lacks a hiera
stand-in and it has no support for any composite data types. It's a
massive dose of deja-vu and it's something that puppet should be able
to compete with. I also think that in terms of language complexity
people flocking to Ansible and similar should be something to
consider, while I love puppet types, when I can use them without
losing puppet 3 support, a lot of people are happier writing YAML with
Jinja2 embeddd in it. And that's a little sad.

Next up European/London presence: Where is PuppetConf Europe? Why are
the London Puppet User group meetings held in such a small space? Can
the next London Puppetcamp have an advanced track and speakers who
don't already have their slides for that talk on slideshare? These are
all exposure issues and without them the start of the community / user
pipeline doesn't stay filled.

And lastly, and this is more anecdotal, the upgrade to Puppet 4. It's
a lot of work, it makes people nervous and other than iteration it's
not something that's immediately wish-list fulfilling for people. I've
been chipping away at prepping a large code base to puppet 4 and it's
something people dread the burden of rather than optimistic look
forward to getting new features from. Greenfield Puppet 4 is a big
step forward, it's just an even bigger one to get there if you already
have a large deployment.

I know quite a few places that are mostly cloud backed that would
rather move to the newer model of things like consul and consul
template than try to bring all their puppet up to scratch only to have
to do it again in what feels like another 6 months. The general
communities slow support of it has also created a cycle of pain where
important things module and provisioning platforms took a very long
time to justify and add the support for puppet and so caused a
downstream bottle neck of people finding out their tool chain was
puppet 3 only and deferring their own investigations again. I'll also
take this opportunity to single out the great work David Schmitt did
in helping bring Puppet 4 to puppet-syntax. That kind of outreach to
community projects should happen more.

Dean
--
Dean Wilson http://www.unixdaemon.net
Profanity is the one language all programmers understand
--- Anon

[Ryan Whitehurst]

On Tue, Apr 12, 2016 at 10:54 AM, Dean Wilson <dean....@gmail.com> wrote:
> AWS: Over the last 5 years I've deployed a -lot- of AWS and spoke to a
> lot of people about it and unless they are a large enterprise
> forklifting their current environment over or looking to run a few
> bits of code at instance time, and just happen to have admins who
> already know it, puppet doesn't really enter the equation. I remember
> evaluating Puppet support for AWS resources about 4 years ago, finding
> it in a very nascent state and then checking in every 6 months or so
> and discovering that it's essentially not moved. To ignore such a
> large player and platform these days is a massive negative to a lot of
> potential users.

The puppetlabs-aws module [1] is pretty powerful these days -- we on
the operations team here at Puppet use it for managing a large portion
of our AWS infrastructure. Along with Daniel Dreier's autosign gem [2]
and associated puppet module [3], we can fully automate the
provisioning and deprovisioning of the majority of our AWS
infrastructure. I'm hardly an expert on AWS, though -- are there
critical features for you that it is missing?

[1] https://forge.puppet.com/puppetlabs/aws
[2] http://danieldreier.github.io/autosign/
[3] https://forge.puppet.com/danieldreier/autosign

[Dean Wilson]

On 12 April 2016 at 19:16, Ryan Whitehurst <r...@puppet.com> wrote:

> The puppetlabs-aws module [1] is pretty powerful these days -- we on
> the operations team here at Puppet use it for managing a large portion
> of our AWS infrastructure.

If you remove the Route53 DNS record resource types then that module
claims to support about 21 AWS services. Terraform supports about 130
in the currently released version. And that'll increase in the next
release as their new service adoption rate is staggering to watch.
Even Ansible has over 50 AWS resource management modules. Some of the
gaps are pretty high in the environment bootstrapping order too - IAM
roles for example. If I went puppet-aws as my tool of choice I can't
even add other IAM users without going back outside my config
management. This isn't just a rush to add new services either, those
are more mature services that have been around for a long while.

I can see how for lift and shift AWS deployments you can get quite far
with the instance and networking types puppet-aws provides but if
you're looking to embrace AWS as a platform it very quickly loses out
in comparable features. There might also be an issue here for how
difficult it is to write a solid puppet type and provider but I'm not
fairly placed to answer that.

> Along with Daniel Dreier's autosign gem [2]

To be honest running a puppetmaster in AWS is a bit of a losing battle
architecture-wise. I've seen PuppetDBs run happily but the master
itself is a bit of a mismatch to the kind of architecture you want to
be moving towards. That's a bit of a tangent though.

[R.I.Pienaar]

Every time I try to play with the puppet aws resources I end up wanting
to reference data in other resources and cant.

resource "aws_instance" "web" { .... }

resource "aws_elb" "myapp" {
...
instances = ["${aws_instance.web.id}"]
}

I do not think you can do this with the Puppet resources - couldn't when
I last looked but something could have changed as it's been a while

This is quite a common pattern with AWS since the stuff is very inter
connected and cross referenced.

Is there a solution with the puppet modules for this?

[Andreas Zuber]

On 04/11/2016 07:38 PM, R.I.Pienaar wrote:

On 11 Apr 2016, at 17:45, Eric Shamow <eric....@gmail.com> wrote:

On April 11, 2016 at 4:08:51 AM, R.I.Pienaar (r...@devco.net) wrote:

----- Original Message ----- 
> From: "Thomas Gelf" <tho...@gelf.net> 
> To: "puppet-dev" <puppe...@googlegroups.com> 
> 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

[Gareth Rushgrove]

Quick correction, mainly unrelated to the main thread. The AWS module
uses the puppet name for reference, you never have to deal with the ID
directly. So the following should just work.

resource "aws_instance" "web" { .... }

resource "aws_elb" "myapp" {
...

instances = ["web"]
}

Gareth

> I do not think you can do this with the Puppet resources - couldn't when
> I last looked but something could have changed as it's been a while
>
> This is quite a common pattern with AWS since the stuff is very inter
> connected and cross referenced.
>
> Is there a solution with the puppet modules for this?
>

> --
> 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/2021155169.607149.1460487846366.JavaMail.zimbra%40devco.net.

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

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com

[Trevor Vaughan]

I've been staying out of this thread for various reasons, but Rob's statement on "Puppet for CM and Ansible to Orchestrate it" resonates well with me.

One of the big benefits that I see with the Puppet DSL is the understandability of the language.

I can show the DSL statements to most people and, when cleanly written (please don't be clever), I can communicate the intended state of the system in a relatively short timeframe to *non-technical* personnel.

I can model business logic and I can present that business logic in an understandable fashion. When necessary, I can drop down into pure Ruby and do whatever I need to do. However, that capability is controlled behind a consistent API and provides a consistent and understood mechanism for controlling my systems. This means that I don't end up with 5 developers and 5 different styles across my Ruby space.

This is *important* in multiple industries, particularly highly regulated industries.

However, with the exception of the recent Orchestration capabilities that are 4.X only, use something else for Orchestration. MCollective, Ansible, whatever....

But, keep your business and security rules understandable and able to be maintained by someone other than you.

I think that using 'puppet apply' in cloud environments hasn't been getting a lot of press, but it is very powerful when faced with writing loops in YAML. (You *can* write the YAML catalog by hand, but please don't).

Finally, the SIMP project that I lead is a large infrastructure oriented project and we are, right now, going through the 3.X to 4.X migration phase. I wanted to chime into note that this has not been *hard* this has been *tedious* and required better testing in our modules. This is not a bad thing since we found bugs in our modules that we did not know existed previously. However, we are absolutely feeling the pain of the AIO installer and will be creating a mess of symlinks to ensure that upgrading existing systems works as expected. It's not a wonderful approach, but it should allow for rolling systems back and forth between 3.X and 4.X with impunity.

Also, you still don't need PuppetDB if you don't want to use exported resources (we don't use them due to graph explosion if not carefully controlled) and, as pointed out in other threads, the API is standardized so you can use another solution as long as you implement the API.

This, fundamentally, is one of the biggest advantages that I see to the 4.X ecosystem. The language was formalized and the APIs were standardized. To do this, some backward compatibility had to be broken, but (in theory) it was broken in the name of maintainability and stability over time.

Full disclosure, my company is a services partner with Puppet Labs but, also full disclosure, we regularly review the automation space and will happily toss tools to the side if something more effective for our use cases and customers presents itself.

Thanks,

Trevor

--

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/CAC76iT9m79fVxWYZE6q9ypnV1XmZWw1_6vMCMT_m_-DFftwfyQ%40mail.gmail.com.

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

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

[James Turnbull]

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

Actually I said that and I don't work at Puppet (Labs). It's also still
true.

Kind Regards

James Turnbull

[Luke Kanies]

On Apr 11, 2016, at 4:08 AM, R.I.Pienaar <r...@devco.net> wrote:

----- Original Message -----

From: "Thomas Gelf" <tho...@gelf.net>
To: "puppet-dev" <puppe...@googlegroups.com>
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.

Wow. This is, ah, comprehensive. I’m not going to try to respond to all of this, but I’m going to do what I can to reply to the core concerns in a couple of these emails.

In any replies you might make, it’s safe to assume that most of the things we’re doing that you don’t like aren’t being done by “Puppet”, they’re being done by me, and/or by someone else on this list who works somewhere in my organization. That is, there is no “Puppet”, there’s just the group of us doing what we can to build a company to automate the world. Not sure if that matters, but it is worth pointing out there are people you can have these conversations with at any time, and those people are easy to find.

In particular, I’ve specifically been leading the strategy for deciding how to keep our OSS software healthy and great, our community strong, and our business viable, so a lot of those decisions were either made by me, or made in direct consultation with me. I’m definitely the right person to bring these questions up with, although in so many cases, we’re still learning.

It is worth pointing out that I consider OSS and community to be clearly related, but more orthogonal efforts to increase the area of a curve, rather than the same thing. It’s very easy to think “OSS == community”, but there are plenty of fantastic communities around shared identities, shared content, shared experiences, and shared goals; it doesn’t all have to be shared code. In our case, Puppet’s community has always been much more of a user community than a developer community, and we’ve invested more in the user community than the dev community (which I think is both rational and the right decision).

As we work hard to figure out how our business will work over the next ten years, it’s worth reiterating that community will always be critical to me. It’s how we know we’re building good software, it’s how you succeed (because people help each other), and in a lot of ways, it’s what makes it worth it. Having users say again and again that Puppet made their lives better is what keeps me at this.

Everything I do is in relentless pursuit of giving more people the opportunity to get the benefits that Puppet and related tools have so far given to a small slice of the world.

As a last point, today we at Puppet have more people working on OSS and are shipping more OSS than we’ve ever done before, and I’m incredibly proud of that. The fact that the percentage is smaller in no way diminishes the total amount of work we’re doing here.

[…]

Open Source users often see the existence of some open source tool as a implied
contract that it will always be so, and their adoption of it is based on that
perception.  This is encoded in the very licences we hold deer and when that
inevitably turns out not to be realistic business model the companies involved
will do what they can to survive.  Inevitably this ends up breaking the
‘implied contract’  the open source user rightly or wrongly felt they had - cue
much anguish and resentment.

Not surprisingly, I have a lot of opinions on OSS in the world of software companies, and again, not surprisingly, some of my opinions have shifted dramatically over the last 11 years. It’s not a coincidence that only two or three public-size companies built on OSS have ever reached sustainability (Red Hat, Sourcefire, and…?). We’re trying to do something so fundamentally hard that only a few have ever done it, and we can’t repeat the ways they did it. Everyone else who has tried is either still in process (Cloudera, Hortonworks) or ended badly (MySQL).

There is a ton of successful OSS out there, but almost none of it is produced by companies like us, who are building their company around making you successful. Instead, it’s almost all built by companies like Intel, IBM, and HP, who are contributing to a project as part of a larger strategy. It’s a loss leader in some way for some other project.

We don’t have that luxury. We have given away the thing you find most valuable about us, and yet we still have to find a way to build a business capable of sustaining the software you rely on, and hopefully actually do much more than that. Certainly I’m not running this company to maintain the status quo.

And that gets to my last point. We are still very, very far from the whole market being automated. My goal is above and beyond all else to get the whole market automated. Providing great open source software is a critical part of the goal, but building a large, successful company that my customers love is another big important part of that goal, not because I’m greedy, but because I want to do big things, and big things require big levers.

And in terms of implied contracts, the only thing encoded in your OSS contracts is your right to use what’s posted. Encoded in our community is our own standard of software, which is that we work hard to build software people love, and we think its users and the community around it matter a lot. We don’t succeed all the time, but more importantly, for us to even consider keeping that promise, we have to constantly evolve, we have to stop maintaining some projects (which you can then take over, if you’re so inclined, because it’s OSS), and we have to start new ones.

In other words, our license entitles you to the code included in that repo. Our community has a statement of how we expect to work, and your engagement in that community gets you far more rights than any license ever word. The reason my team works so hard to make you, and everyone else, happy has nothing to do with OSS. It has everything to do with community.

I wish I could say that the community was responsible for Puppet, and so many of the tools around it. Certainly I can say that you, RI, have contributed incredibly important work to Puppet. But in general, the software itself is maintained by people who Puppet pays.

The company will then go on to explain themselves and make commitments - we
will keep the core product open but innovate on paid for enterprise features
like RBAC and very featurefull GUIs.  We will not work to exclude other makers
of tools and your home grown tooling, we will make the extension points open
and APIs open for others to innovate on.

I don’t have the actual quote to hand as I am sat on a plane but this seems to
me more or less the story we were told when PE became a thing and that seemed
good and a model worth supporting. After all what would be open source is not
unlike most other open source and we are not averse to applying some duct tape
and glue to make things work.

I’m sure I’ve said some of these things, but I’ve also said plenty of other things. That’s more about helping everyone understand how we’re working today, rather than a long-term commitment for how we’ll always work. I stood up at PuppetConf more than a year ago and said we’d tend to build commercial software in the core and OSS at the edge. Note that’s not “we’ll commercialize stuff in the core”; just, net new projects that I fund will follow this pattern.

I’m proud that we wake up smarter every day, that we learn, that the way we work today is unlikely to be the way we work tomorrow.

I’m proud we’ve built a lot of great software over the years.

I wish I was proud of every decision and every piece of software, but, well, that’s the way of it.

Fast forward to now and the situation is not like this at all.  Today we have
the puppetserver product touted as the only way forward and not only does it
have PE only APIs its core operability features are PE only too.  Performance
metrics and atomic deploys.  No longer is it a matter of if you put in the
effort and build the tooling you can use the Open Source product but we will
sell world class tooling.  We’re now in a world where the ability to monitor
the product and gain the insight you need to scale it requires you to adopt a
per node based payment model.  Being able to monitor a service only when you
pay for it. I am not sure I've seen a worse model for the 'free' users.

Hmm. I read this as, we built a much, much better Puppet server, that’s faster, more stable, more scalable, lighter weight, and much more, and then given it away for free. For zero cost on your part, you have an unquestionably better product in pretty much every way.

We’ve also decided to do more work beyond that, but not release all of it for free.

That other work was never available in the old system. That other work was never available for free. And no matter how much you might be interested in paying, you couldn’t get those other features with the old system.

From my perspective, everyone wins here:

People unwilling or unable to pay for software get a much better product.

People who pay for the software get a better product and some additional functionality.

We can afford to continue investing in the product and making both the free and commercial bits better every year. 

Now tools like Foreman cannot compete because they cannot monitor the master
and they cannot have atomic deploys. Who knows whats future PE only APIs will
come? I'd bet things around file serving, catalog life cycle management etc.

Red Hat — which funds Foreman — can easily compete. So far, though, they haven’t contributed any patches, asked for any help, or done any of the work implying they care about it. Heck, they could do what we did, and build from scratch a brand new system that works better, is faster, lighter weight, has support for operational metrics, and then given everything away instead of nearly everything. I know for a fact Red Hat has a ton more developers than we do, they just don’t have any devoted to working on Puppet itself, or any of the core systems in it.

Now similarly open source users cannot compete because they cannot gain the
insights they need to scale this java blackbox, even if they invest the time to
learn the JVM, the software in the JVM is actively resisting their efforts of
gaining operational insight. Their own tooling cannot compete against PE
because some APIs are PE only.

I’m not really sure what you mean by ‘compete’ here - Foreman is run by Red Hat, who is basically a competitor from this perspective, but the users you’re talking about aren’t trying to compete with us, or anyone else, so I don’t know how ‘compete’ fits in.

Personally as a open source user I use ‘apply’ - I decided during my P4
migration to look again at using a master - puppetserver - and was all set to
move machines onto it that weekend when the metrics blog post came out.  The
puppetserver VM got immediately deleted.  This is not a future direction that
is cooperative or long term tenable for me.

If you’re a open source user you need to look very carefully at the messaging
and feature set and you can really only come to one conclusion and that is that
to Puppet you’re just not a priority.  Less than a priority you’re effectively
being locked out and worked against and lack the ability to make a well
monitored CM system if you adopt open source puppet.

I’m sorry, but this is just not fair, and I think this perspective harms all of us.

If OSS users weren’t a priority, we wouldn’t be actively posting so much new free software. Puppet-server would be a commercial replacement for the puppetmaster, the compiled Facter would be commercial, the compiled Puppet language would be, etc. We wouldn’t have had Henrik spend so much time making the language do what so many always wanted.

These are all examples of us spending a ton of money, time, and energy building software that makes your life better for free. I don’t know what else we could do to convince you that this matters to us, other than just literally give away everything we do, but if we did that (which we did for 7 years, so I have a lot of experience with its consequences), you’d have a worse product (because relying on services would innately push us to build a product that needed services work) and we’d probably be out of business.

I hope the metrics situation will change - there has been other PE-first
features and they came to Open Source so its not unprecedented but in this case
it will pay to wait and see since if these features are not coming to Open
Source then the whole is unusable.

Strategically we rarely build commercial features with the plan for them to be free; we generally (but not always) intend on a given capability being free or commercial through its lifetime.  I think that’s a much better and clearer picture for everyone — if you’re using all free software, you’re using the latest and greatest, rather than planning for OSS users to only have years-old features.

I would be happy to have a conversation about whether we’ve made the right decision on this being OSS or not, but frankly, this is the first I’ve heard this complaint from anyone outside the company.

It’s a pendulum that swings, whats the right answer and right balance is not
black and white.  It’s a fiendishly difficult business problem and you have to
commend Puppet for even bothering with Open source at all this point so I try
and see the good intentions towards the open source user base. And while I am
quite negative in this mail I do not think they are maliciously working towards
excluding us.  Hopefully Puppet realise in these cases the pendulum swung too
far and will correct the course.

That’s good to hear, at least. Hanlon’s razor. :)

Either way, the signal to Open Source users is that you need to really deeply
consider your options post Puppet 3. It’s undeniably a high risk situation. It
might well be the most significant decision you make in the next 5 years of
your infrastructure and of your career.

On the points of migrating to P4 from earlier Puppet.  Its a major problem.
Not only did the entire system change - in every respect, every component has
had a major rework and rethink from 2.6 days but the language have also in
effect become a new language. Not surprising for a 10 year old product.

We’re very much feeling the pain of the upgrades here, but that has nothing to do with OSS or anything else. It has to do with us moving from a very informally designed language that I built, to a much more formally built language that Henrik has formed it into. That, and people really hate to upgrade, especially on-premise software.

We’ve recognized the gap here, and will be working hard to help people through that. It’s fair to say that I consider our community’s success at upgrading to this version — or at least, staying on what we consider to be the latest version of the language — to be an existential question.

For what it’s worth, one of the long-pole priorities in our business overall is to keep a huge portion of our community on the latest versions. I know we haven’t succeeded at that in the past, but it’s something you’ll see us continue to invest in heavily indefinitely. And that should help all users.

[…]

There is not much more frustrating and insulting than a company who puts you in
that position and needless to say if the effort has to be put in anyway they
will look elsewhere.  I suspect the paying customer base will approach the
transition similarly.  I have no data on this but would be interesting to know
how many old PE users are transitioning to P4 based PE once the older support
cycle ends.

For what it’s worth, I would absolutely love to lock in a given piece of tech and just leave it. But then we get accused (rightfully) of abandoning things.

We have to walk this tightrope between always being modern but never asking our users to change.

I think P4 was comfortably too much change in one go, and we’ve got work to do to recover from that. But a lot that went into P4 is in response to users all over the community asking for them.

I am deeply sympathetic to these people and it’s sad to say but where we are
today is that they are simply SOL and there is no light at the end of the
tunnel when you can’t even have a hope of gaining deep insight into New Puppet
without paying.

I’d argue no one could get any insight into the old system regardless of willingness to pay, so again, every member of the community is better off with the new system.

[…]

I felt I had no choice but to approach it this way because as a Open Source
user the future is not bright at all - as per my previous mail I am just not a
priority - and I can’t really blame the company for feeling this way.

I think you’ve pegged yourself incorrectly.

You’re a Puppet user, but you use plenty of commercial software (e.g., your phone, which is probably as critical to you as Puppet is). Richard Stallman is the only OSS user I know.

Your particular use cases are unlike most of our customers, so there is some dissonance there. I don’t know of anyone who runs as much infrastructure individually as you do, especially not for R&D. You’ve decided that it’s not worth paying for our software in this space, which is (I assume) a rational decision on your part, 

I’d use PE as I have nothing against it but as this is a R&D network the $3000
licence for my node count I’d need does not seem like a good way to spend my own
pocket money.

I myself am bout 50/50 through my P4 migration and it’s been a daunting task to
say the least - though I am under no time pressures and am taking the time to
gain a deep insight into what P4 is, what motivates its existence and to regain
the deep understanding I had of < P4 and so forth.

I am though a consultant in this space and Puppet is creating a massive
customer base for what I do so it’s not like its wasted effort for me, as was
pointed out, I am not typical though. Given the amount of money out there for
consultants in a world Puppet literally create from nothing - wearing my
consultant hat I’d say keep going as you were.  And Puppet does really good
things to support the consultants in their space via partner programs and such.

It’s great to hear this feedback, thank you.

P4 on it’s own is a brilliant tool brilliantly engineered and the language
innovations are really good.  The engineering rigour is orders of magnitude
better than we had before and it really shows in the end result. I have nothing
but positive things to say for P4 and the team that created it.

It’s unfortunate P4 is combined with a supporting eco system that while
innovative, powerful and potentially game changing is making it irrelevant to
me as a class of user since they are more and more approaching things in a way
that locks me out of the future I - and many like me - helped create.

I completely agree many helped create this world, and you personally were and continue to be a big part of it.

— 
@puppetmasterd | http://about.me/lak | http://puppetlabs.com/

[Luke Kanies]

On Apr 12, 2016, at 10:54 AM, Dean Wilson <dean....@gmail.com> wrote:
>
> On 11 April 2016 at 12:08, R.I.Pienaar <r...@devco.net> wrote:
>
>> 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.
>
> Since you asked so politely.
>
> I have a few main areas of concern, and oddly they are not so much
> with the core puppet project. I think most of the work going in to it
> is solid and makes the product more durable and offers a certain
> amount of extra sophistication with things like the type system.

Glad to hear this, thank you.

We have always taken this area seriously, but it’s also never been our core use case.

One of the biggest challenges in our business is finding the balance between helping people with the infrastructure of today but also helping them adopt the tech of tomorrow.

We’ve taken multiple cracks at this stuff (remember cloud-provisioner?) but none of them have really worked out.

I think the work Gareth is leading in this area is a real winner, though, so I think we’re on the right path now.

Obviously we would all do things differently in retrospect, but in truth, I wouldn’t change how I balanced our efforts looking backward. I couldn’t have sold much software in that space over the last few years, so it was correct for us to focus more on people’s production infrastructure. Now that all of our customers are asking how they manage both AWS and on-premise, it’s become critical.

And, of course, it’s worth noting that no one needs our permission to build great tools in this space. Gareth’s work is based on the work he did as a community member, and is just further developed as an employee of Puppet. If it was that important to all of you, you wouldn’t have waited for someone else to build it.

So in the end, I would love to have been able to afford to invest in both at the same time, and to have them both work, but we made a bet as a company, and overall, I’m relatively comfortable with the results of that bet.

Now we just have to take our position today and make sure it translates into leadership in that space, too. :)

> Next up European/London presence: Where is PuppetConf Europe? Why are
> the London Puppet User group meetings held in such a small space? Can
> the next London Puppetcamp have an advanced track and speakers who
> don't already have their slides for that talk on slideshare? These are
> all exposure issues and without them the start of the community / user
> pipeline doesn't stay filled.

I really would love to have a PuppetConf Europe, but we just can’t afford it right now. All of our events run at a loss, no matter how much we charge or get sponsorship — both of which we also get a lot of complaints over — so we have to find the right balance between events to support the community wherever it is, and getting work done on other priorities. Every dollar I spend on an event is a dollar I can’t spend on things like developers, documentation, etc.

> And lastly, and this is more anecdotal, the upgrade to Puppet 4. It's
> a lot of work, it makes people nervous and other than iteration it's
> not something that's immediately wish-list fulfilling for people. I've
> been chipping away at prepping a large code base to puppet 4 and it's
> something people dread the burden of rather than optimistic look
> forward to getting new features from. Greenfield Puppet 4 is a big
> step forward, it's just an even bigger one to get there if you already
> have a large deployment.

Agreed, and we’ve got work to do here.

> I know quite a few places that are mostly cloud backed that would
> rather move to the newer model of things like consul and consul
> template than try to bring all their puppet up to scratch only to have
> to do it again in what feels like another 6 months. The general
> communities slow support of it has also created a cycle of pain where
> important things module and provisioning platforms took a very long
> time to justify and add the support for puppet and so caused a
> downstream bottle neck of people finding out their tool chain was
> puppet 3 only and deferring their own investigations again. I'll also
> take this opportunity to single out the great work David Schmitt did
> in helping bring Puppet 4 to puppet-syntax. That kind of outreach to
> community projects should happen more.

This is a fundamental challenge that every tool in this space will be wrestling with for as long as our space exists. I look forward to having these same arguments every 18 months or so, and to see them evolve in all of the other communities too.

We’ve seen how hard this is, and we’re going to work differently from now on to focus incredibly heavily on reducing the cost of upgrade no matter what. It’s a company-level priority.

—

[Luke Kanies]

In our experience, literally no one we ever talked to could use StoreConfigs in production. You could get maybe 30 machines on it before it fell over, and lite_storeconfigs (thanks Brice!) only helped a little.

That’s a pretty massive value.

[…]

* 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 is no killer feature, other than massive speed increases all around and having a formal language now.

The main killer feature is that there were 100 little inconsistencies in the language that people tripped over non-stop. Being able to push through all of those is the killer feature. I know it isn’t obvious, but it really is about making 100x easier for anyone to approach Puppet, rather than asking every new person to learn where all the traps, mines, grues, and everything else are.

[…]

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

I appreciate the focus on overall product.

We’re definitely way off topic for the list, but we haven’t let that stop us before, so…

I have no idea of your use cases, so I can’t talk about what value you mind in what we’re doing. What other customers have found valuable in latest releases is, well, a ton:

- Dramatically faster, more reliable, scalable, etc.

- Much easier to install, upgrade, maintain, etc.

- Best ever for understanding how the environment is working, what’s broken, where the world is at

- Orchestrator built in now so you don’t need to use two separate tools (no more convergence, no more Puppet+Ansible)

- Really good r10k integration in Code Manager, plus a lot more around it

- Fantastic graph visualization for debugging and prediction

That’s just a couple of things, and maybe none of it matters to you.

I will make sure we get a more forward-looking statement of roadmap-type stuff out soon, but I can’t do that here.

—