Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uninitialized constant Chef::Resource::WinrmConfigListener #13

Open
MichaelStankiewicz opened this issue Aug 21, 2017 · 1 comment · May be fixed by #18
Open

uninitialized constant Chef::Resource::WinrmConfigListener #13

MichaelStankiewicz opened this issue Aug 21, 2017 · 1 comment · May be fixed by #18

Comments

@MichaelStankiewicz
Copy link

I upgraded chef-client to version 13.3, and now when I run my recipe to converge my winrm listeners, I'm receiving the following. It's worth noting that this is working fine on my down-level chef clients (v12.19.36), so this appears to be an issue with something that may have changed in the latest version of the chef client (or something that has changed between these versions).

Recipe: winrm-config::listeners
  * winrm_config_listener[HTTP listener configuration] action configure

    ================================================================================
    Error executing action `configure` on resource 'winrm_config_listener[HTTP listener configuration]'
    ================================================================================

    NameError
    ---------
    uninitialized constant Chef::Resource::WinrmConfigListener

    Resource Declaration:
    ---------------------
    # In C:/chef/cache/cookbooks/winrm-config/recipes/listeners.rb

     27:   winrm_config_listener "#{key} listener configuration" do
     28:     address                    conf['Address']
     29:     enabled                    conf['Enabled']
     30:     certificate_thumbprint     conf['CertificateThumbprint']
     31:     hostname                   conf['Hostname']
     32:     port                       conf['Port']
     33:     transport                  conf['Transport']
     34:     url_prefix                 conf['URLPrefix']
     35:     notifies :restart, 'service[WinRM]', :delayed
     36:   end
     37: end

    Compiled Resource:
    ------------------
    # Declared in C:/chef/cache/cookbooks/winrm-config/recipes/listeners.rb:27:in `block in from_file'

    winrm_config_listener("HTTP listener configuration") do
      action [:configure]
      default_guard_interpreter :default
      declared_type :winrm_config_listener
      cookbook_name "winrm-config"
      recipe_name "listeners"
      address "*"
      enabled true
      certificate_thumbprint ""
      hostname ""
      port 5985
      transport :HTTP
      url_prefix "wsman"
      key "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WSMAN\\Listener\\*+HTTP"
    end

    System Info:
    ------------
    chef_version=13.3.42
    platform=windows
    platform_version=6.3.9600
    ruby=ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32]
    program_name=C:/opscode/chef/bin/chef-client
    executable=C:/opscode/chef/bin/chef-client

@MichaelStankiewicz
Copy link
Author

FYI - I believe I found the specific item that was change in v13 that is breaking the listener LWRP. Per the following release notes link: https://discourse.chef.io/t/chef-client-13-released/10735

DSL-based custom resources and providers no longer get module constants

Up until now, creating a mycook/resources/thing.rb would create a Chef::Resources::MycookThing name to access the resource class object.
This const is no longer created for resources and providers. You can access resource classes through the resolver API like:

Chef::Resource.resource_for_node(:mycook_thing, node)
Accessing a provider class is a bit more complex, as you need a resource against which to run a resolution like so:

Chef::ProviderResolver.new(node, find_resource!("mycook_thing[name]"), :nothing).resolve

@Annih Annih linked a pull request Aug 13, 2019 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant