And this is aside from the significant resistance we've been getting from our traditional Windows admins over using Puppet, which is a problem that Puppet definitely can't solve. Their partnership with Microsoft is a very good thing, in my opinion though.
Oh, and Chocolatey. :D --Alex On Wednesday, May 7, 2014 10:04:23 AM UTC-7, Alex Scoble wrote: > > I'm sorry, I misspoke, I should have said that for us Puppet (PE actually) > has been a moving target in a number of ways. > > For instance, we started out heavily using the PE dashboard to define what > classes specific nodes would get and related variables, pretty quickly > realized that that wasn't very scalable or repeatable and found hiera and > environments. > > Puppet does a decent job of explaining environments, but their > documentation in regards to integrating with git and gitolite is > inadequate, particularly considering that they strongly recommend going > down that path. Oh and while you are researching how to make dynamic > environments work, you invariably run into R10k which sounds really > awesome, but then you wonder how do you use it? > > Dynamic environments are great, extremely useful, but centrally managing > what nodes are in what environment wasn't possible until we discovered the > console_env module, which unfortunately isn't working for us after we > upgraded to PE 3.2 (and to make a point about how the product is a moving > target, they are currently working on a new way of assigning roles to > systems). Hiera is also great as it's much faster to work with than the > dashboard, but it's a lot easier to make mistakes with hiera. Also, for > many situations, you need a hiera yaml file for individual nodes (like when > you want a group of systems to use a specific class). So now there's the > roles and profiles pattern, which Puppet recommends using along with hiera, > but they don't provide good documentation at all on how to use both > together. > > Plus if you pay attention to R.I. Pienaar (and you definitely should, in > my opinion), you see that he's proposed a new pattern where you use hiera > data within modules, but getting that to work requires using one of the > modules that aren't yet in a finished state... > > I've talked to people who don't think that Puppet has handled the way > they've added features and patterns and deprecated other features and > patterns, but we haven't personally run in to that. > > All in all, I love the product, don't get me wrong, and maybe it looks > pretty stable when you're at the guru level and figuring out new stuff is > fairly easy, but for me, it's just me and a coworker trying to mature our > linux and puppet infrastructure, processes and workflows. Neither of us are > developers, so are learning that side of things as best as we can while we > learn Puppet, git, hiera, Geppetto (which is the bee's knees, just be super > careful when you try to merge two significantly different branches together > using it), beaker, rspec, ruby and so on. > > I'm always questioning our choice in tools because that's how you stay > ahead in this game and when I go looking for why people are using Salt > Stack and Ansible instead of Puppet or Chef, the number one reason I've > seen is complexity of the code needed to do something. > > Having said that, now that I've figured out a number of things and can > pretty much do anything I want with Puppet, albeit crudely (you can see my > kvm/webvirtmgr module as evidence of this), I don't see a reason to switch, > but I can certainly understand why some people may look at the DevOps space > and gravitate towards Salt Stack and Ansible over Puppet. > > Thanks, > > Alex > > On Wednesday, May 7, 2014 1:18:49 AM UTC-7, Felix.Frank wrote: >> >> On 05/07/2014 12:52 AM, Ramin K wrote: >> > >> > I find it best not to change my workflow or methodology until it >> > makes sense on my system regardless of what the community or even >> Puppet >> > Labs has said. >> >> Ramin, I could hardly agree more. Even your ignored practices resemble >> my own personal choices very closely (those perhaps come rather natural >> to old schoolers). >> >> If I understood Alex right though, he also feels that the apparent flux >> might be hindering broader acceptance of Puppet. If that is indeed the >> case, we have a problem that we should talk about. (Note that apparent >> stability is more important than the technicalities.) >> >> However, it has been my feeling that general adoption is not one of >> Puppet's problems. On the contrary, Puppet users usually form the >> largest crowd in any kind of forum concerned with the configuration >> management problem. The user base keeps growing and the community is >> literally buzzing with activity. >> >> Alex, are there concrete issues that you have faced concerning the ease >> of adoption? >> >> Thanks, >> Felix >> > -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users/ee39c63d-b977-4662-a2a2-fcc30c1943ed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
