This comment has been minimized.

This feels like we need a default exists? accessor in FilterTable that can be added with .add_accessor. Obviously don't address this as part of this PR, but I've seen this multiple times so it feels ripe for consolidation.

This feels like we need a default exists? accessor in FilterTable that can be added with .add_accessor. Obviously don't address this as part of this PR, but I've seen this multiple times so it feels ripe for consolidation.

This comment has been minimized.

difficult, since init system is not necessarily tight to a specific operating system. Chef is the best example and uses runit. I know we need to extend this in future. Maybe we kick this out of the resource, let me think about it

difficult, since init system is not necessarily tight to a specific operating system. Chef is the best example and uses runit. I know we need to extend this in future. Maybe we kick this out of the resource, let me think about it

This comment has been minimized.

@chris-rock Oh sure, totally. The Chef example is a good example, but it's also an example of where an installed application is providing its own process supervision vs. what the OS default is. It's pretty hard for someone to take a CentOS 7 box and convert it to be upstart natively, so it still feels like there's a pretty strong connection to the OS and the expected init system.

We're at least making that assumption now in two resources... Not sure the right way to solve it, but duplicating it feels wrong. 🙂 Shouldn't block this, but we should probably add an issue to solve init detection if more resources are going to rely on it.

edited

Edited 1 time

adamleff edited Apr 19, 2017 (most recent)

Contributor

@chris-rock Oh sure, totally. The Chef example is a good example, but it's also an example of where an installed application is providing its own process supervision vs. what the OS default is. It's pretty hard for someone to take a CentOS 7 box and convert it to be upstart natively, so it still feels like there's a pretty strong connection to the OS and the expected init system.

We're at least making that assumption now in two resources... Not sure the right way to solve it, but duplicating it feels wrong. 🙂 Shouldn't block this, but we should probably add an issue to solve init detection if more resources are going to rely on it.

This comment has been minimized.

@adamleff Yes indeed, that is why we assume the default in our resources which is the only sane thing. If customers have a custom one, they can use runit_service etc. Detection of the init system is not easy, especially since they have fallbacks implemented, too. I am going to remove that feature for now, since I am not considering it as stable

@adamleff Yes indeed, that is why we assume the default in our resources which is the only sane thing. If customers have a custom one, they can use runit_service etc. Detection of the init system is not easy, especially since they have fallbacks implemented, too. I am going to remove that feature for now, since I am not considering it as stable