Python dependency

[3v]

Python cookbook is deprecated and is suggesting to use poise-python instead.

[luckymike]

This will remove Chef 11 support, which is fine, but needs to be a major bump which arguably requires a little planning. Then again, it's not like other features have been flowing to the current major version :)

[tas50]

it's time to do the bump at this point. Chef 12 has been out for 18 months and we've removed support for Chef 11 from all chef managed community cookbooks. This cookbook already depends on cookbooks that require Chef 12.

[howdoicomputer]

This would also make it easier to use PyPy. I saw a branch for migrating over to poise-python done by @luckymike but it looked abandoned. Would contributions be welcome? I could do the migration work.

[luckymike]

No really abandoned, just held on the question of ditching Chef 11, which I think is resolved.

[webframp]

agreed! I think we can assume Chef 12 only at this point.

[howdoicomputer]

Sweet! Thanks for chiming in. Good to hear that goodness is coming.

[tas50]

I'm currently working on a getting a working graphite cookbook out the door. Graphite expects Python 2.7 now, which bumps the Django dep and changes a lot of config steps. This is currently going on in #266. After that I plan on cutting a Chef 12.1+ release using some of the new custom resource accumulator logic we've developed at Chef. This new release will also remove the use of Runit, and instead use Upstart/Systemd depending on the distro release. That makes it easier to test since Runit fails in kitchen-dokken and also allows for openSUSE support where there aren't runit packages.

[howdoicomputer]

@tas50 That sounds fantastic!

Does runit really not work in dokken? I just setup a wrapper cookbook and converges for the single_node recipe at least complete.

  User root
     ✔  should exist
     ○  This is an example test, replace with your own test.
  Port 80
     ✔  should not be listening
     ○  This is an example test, replace with your own test.

Test Summary: 2 successful, 0 failures, 2 skipped
       Finished verifying <default-ubuntu-1604> (0m0.68s).
-----> Destroying <default-ubuntu-1604>...
       Finished destroying <default-ubuntu-1604> (0m1.32s).
       Finished testing <default-ubuntu-1604> (3m53.32s).
-----> Kitchen is finished. (3m53.96s)

[tas50]

Randomly blows up for me in Travis.

[webframp]

Seems like it would just be a matter of getting the right pid_one_command?
ref: https://github.com/someara/kitchen-dokken#process-orientation

I don't mind removing the default of runit, but removing completely seems like a bit of a departure from current functionality?

[luckymike]

👍 to @webframp's comments. Also, adjusting a cookbook's behavior to facilitate an arbitrary test platform seems like a major anti-pattern.

[tas50]

The goal is definetly not to adjust the behavior for the tests. There's ways to tweak the testing to make things work. Here's a few reasons we've systematically removed Runit from cookbooks that Chef manages.

1. Runit as a project is basically dead. I'm fairly certain this has a lot to do with Added encrypted data bag functionality #2
2. Runit was used extensively in Chef since at the time we only had sys-v and that didn't provide reliability. We needed something that could start services back up when they failed and had easy to write definitions. Modern init systems (upstart/systemd) provide the reliability we need and their definitions are dead simple to write. We even have built in support in Chef for systemd_unit files which makes things even better.
3. Runit is confusing to those not familiar with it or expecting a runit service. Logs in /etc/ is really weird to people and in general a user probably doesn't want/expect runit to be running services setup by cookbooks. Native init systems provide the experience people most likely want / expect.
4. Runit is not available on every platform so we limit our platform support by using runit. The installation on RHEL is questionable at best since it's not an official package and there are no suse packages.

[tas50]

Here's an example of a cookbook that previously defaulted to runit. We migrated service management over to a custom resource and retained runit support, but removed it as the default. If you REALLY wanted it you could keep it, but otherwise you'd get a new service running on a native init system.

https://github.com/chef-cookbooks/push-jobs/tree/master/resources

[luckymike]

I think those are good points @tas50, and I'd welcome a runit 🔪 in v3.0. I think v2.x should focus on updating the python dependencies, dropping Chef 11 support, and adding in the new init options, as those are either enhancements or fixes for existing users.

As I've apparently been removed from this cookbook org, I guess these are user rather than maintainer suggestions. 😛

[webframp]

@tas50 sounds reasonable to me, as long as runit is available as an option to any who need it