There are a lot of very valid issues and concerns you bring up here. I do want to start by saying, however, that puppet 4 is more than 6 months old - about 20 months to be precise - and most of the significant language changes were introduced somewhat earlier in the future parser in puppet 3. These changes should be easier to take in for sure, but that is at least 3x more to catch up on. I hope that doesn't sound like a harsh response, but I think it's more accepted that after 1.5-2 years, most moving projects will require significant re-learning.
Re: ntp module. Puppet supports a ton of operating systems and most of us only run a handful. The module is more complex than any one person usually needs, but it also addresses everyone's needs. From a user perspective, though, it's pretty simple to just `include ntp` unless you want something nonstandard. I think most modules are written this way, certainly the best ones are. Data in modules is an approach to try and reduce the complexity of the code and retain the support for a wide array of operating systems. As a fellow module author, I am struggling somewhat with this myself. There are some good articles about this but I would love to see even more explanations and examples of how to convert from puppet 3 style to data in modules, everyone learns differently. On Travis CI, are you seeing failures related to puppet or dependencies? If it's ruby, I have many feels that I can't share publicly. But the summary is, it's a crapshoot what dependency will break today. I've started setting up Travis Cron Jobs for this, so nightly builds occur before my once a month PR that goes red. My best suggestion is to take a look at Vox Pupuli's modulesync configs, or the dynamically generated .travis.yml in a repo, to keep apprised of what Gemfile settings work. Links: https://rnelson0.com/2016/12/15/scheduling-regular-travis-ci-builds-with-cron-jobs/ https://github.com/voxpupuli/modulesync_config/blob/d4e999bf434dd220614b80c108f7221eb5f3c1db/config_defaults.yml#L18-L56 https://github.com/voxpupuli/puppet-archive/blob/master/Gemfile For remote agent runs, I think that is a very interesting idea. While it has some security implications (agent->master port 8140 vs compile->agent port 22) and fact collection would not work as-is, it could be very useful.I wonder if the `puppet device` face could be either adjusted for that or a base for experimentation? I tend to agree on difficulties with mcollective as orchestration, but I haven't found an orchestration tool that has been simple. Ansible has its issues, too. I just don't think use of another tool is horrible, though. The combination of modules like puppet_agent to upgrade puppet or other components on agents and PQL to query puppet and application orchestration to direct action on PQL results looks to be an appealing combination of puppet-only tools. I've only gotten to play with the modules portion and hope to play with PQL and AO soon to see how realistic that assessment is. If your Travis issues are with puppet itself, can you share some details? On Sat, Jan 7, 2017 at 9:00 PM Jakov Sosic <jso...@gmail.com> wrote: > Hi guys, > > > this is maybe a topic better suited for -dev list, but, well, here goes. > T time. > > > I've been using puppet heavily for 3-4 years, up until version 4, now > > I'm mostly maintaining my own open source modules. > > > > What stumped me lately is the amount of changes that are happening. > > > > > > Every week/two-weeks I do some code changes, and since I tried adding > > some of the spec tests through TravisCI, I've encountered errors about > > `validate_string` being obsoleted. > > > > Then, looking deeper into the rabbit hole. I've encountered this: > > > > https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/init.pp > > > > And I was shocked... :D WTF just happened? :D > > > > > > > > It's becoming overwhelming to follow all these changes even for a puppet > > veteran, what about newcomers? > > > > I've been using ansible for a year due to requirements in my new > > position, and I've been gaining understanding why is puppet seemingly > > losing ground vs other CM tools. It's like the puppet has become a > > purpose of it's own, and not a tool to solve actual problems... > > > > Don't get me wrong, I did survive migration from sysv to SMF, sysv to > > systemd, mmap to wiredtiger, and gazilion other changes, and I'm not > > some old grumpy guy :) But... coming back to a tool after 6 months of > > absence and finding that I have difficulties reading and understanding > > code? Doesn't really make sense... > > > > And, on the other hand - all this complexity to manage a NTP? > > > > > > And again - there are features that are really lacking - for example: > > > > 1) Remote agent runs, meaning: > > - local puppet compiling manifest > > - ssh-ing into a box, scp-ing all the needed shit > > - applying catalog over there > > > > This would eliminate a need for master server (or code living on all VMs > > in case of masterless puppet) for smaller installations. > > > > 2) Something like search function in chef instead of exported resources > > and puppetdb > > > > 3) Simpler and more integrated orchestration - mcollective is > > over-engineered and learning curve is almost vertical uphill battle. > > > > I've been using exactly ansible to orchestrate puppet managed > > environments :) And when you hear that from a 4-5 year-old puppet user - > > that means something is wrong in this ecosystem. > > > > 4) Built in management of cloud infrastructure resources (ec2 instances, > > ami images, etc) > > > > > > Sorry if I offended anybody here, it was not my intention... I hope > > community picks up some hints from my rant... Maybe I completely missed > > the ball, but since I was/still am passionate puppet user, I had to > > share this with community. > > > > Please don't be harsh in your comments ;) > > > > > > -- > > Jakov > > > > -- > > 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/d7250279-33b4-9d91-445c-7eaf81a13b14%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > > -- 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/CAC76iT8%2Bw%2BVkhHVY0JxUREBp%2BuHMh%2B2becrRpLGcv-Nyh1BDTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
