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 puppet-users+unsubscr...@googlegroups.com. 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.
