@haidangwa can you please rebase instead of doing a merge commit update to keep the history linear? Also please address the chefspec issues.

@haidangwa looks like we need to deal with some Chef 17 issues before we can get this merged unfortunately.

@ramereth I'm running the latest chef-workstation on my laptop and the test for uninstall-forwarder passes in Test Kitchen with Chef 17. I'm not sure why this is failing in Github Actions.

@haidangwa I can replicate the problem on my end with 17.1.35. I suspect it has something to do with the systemd? helper included the cookbook conflicting with something else. That really should use chef-utils helpers IMO, but that would increase the Chef Client requirement (which we're going to need to do anyway).

The issue is between Chef Infra Client v17.0.150 and 17.0.242.

All tests pass under v17.0.150, but the uninstall-forwarder tests fail under 17.0.242

@ramereth

@ramereth I've narrowed this down even further. Using kitchen-dokken, the chef infra clients pass all the way through and including 17.0.194. It breaks between 17.0.194 and 17.0.199. That seems definitive that it is a Chef Infra Client bug.

17.0.194: PASS

CHEF_VERSION=17.0.194 KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen converge uninstall-forwarder-amazonlinux-2

17.0.199: FAIL *uninstall-forwarder test suites

CHEF_VERSION=17.0.199 KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen converge uninstall-forwarder-amazonlinux-2

based on tags from docker hub

looks like ruby 3.0.1 was added to the chef omnibus_overrides.rb between v17.0.197 and v17.0.198

diff --git a/omnibus_overrides.rb b/omnibus_overrides.rb
index d20d702d73..32c2cc6e69 100644
--- a/omnibus_overrides.rb
+++ b/omnibus_overrides.rb
@@ -16,7 +16,8 @@ override "ncurses", version: "5.9"
 override "nokogiri", version: "1.11.0"
 override "openssl", version: mac_os_x? ? "1.1.1k" : "1.0.2y"
 override "pkg-config-lite", version: "0.28-1"
-override "ruby", version: "2.7.2"
+override "bundler", version: "2.2.15"
+override "ruby", version: "3.0.1"
 override "ruby-windows-devkit-bash", version: "3.1.23-4-msys-1.0.18"
 override "util-macros", version: "1.19.0"
 override "xproto", version: "7.0.28"

I think getting this cookbook to be compatible with Chef Infra Client 17 is beyond the scope of this PR. Fixing the changes to be Chef 17 compatible should be in itself a separate Pull Request.

@ramereth OK. With all that said (above), I am thinking the problem is in the service provider/resource; perhaps the recent changes to the service resource in Chef 17. In my custom resource, splunk_installer, it calls two helper methods, and both helper methods are referencing the node data.

  service 'Splunk' do
    service_name server? ? 'Splunkd' : 'SplunkForwarder'
    action systemd? ? %i(stop disable) : :stop
  end

Note: server? and systemd? are helper methods declared in libraries/helpers.rb and both return true/false after making a comparison using a node attribute.

    def server?
      node['splunk']['is_server'] == true
    end

     def systemd?
       node['init_package'] == 'systemd'
     end

However, the error does not fail for the server? and fails for the systemd?. It is perhaps a bug in the service provider's action argument.

It's also not that the custom resource doesn't have access to the node object, as I confirmed this by adding a log resource right before my custom resource uses the service resource. My log resource did not fail in my test.

  log "init_package is #{node['init_package']}"

  service 'Splunk' do
    service_name server? ? 'Splunkd' : 'SplunkForwarder'
    action systemd? ? %i(stop disable) : :stop
  end

In fact, it worked fine, as demonstrated in my chef run output, below:

    * log[init_package is systemd] action write

@haidangwa so it looks like some of the fixes you have in here were done in #215 and conflicts with this. Can you please rebase and resolve the conflicts? Thanks!

Hey @haidangwa can you reopen this PR when you have a clean branch. Thanks!

Looks like some great work here.