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 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/neeuoi%244t9%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
