chef-boneyard/chef-api

Role wont save to Chef Server

Closed this issue · 26 comments

Even a simple call wont work.

@role = ChefAPI::Resource::Role.fetch('test_role')
@role.save!

The output is:

ChefAPI::Error::HTTPBadRequest: The Chef Server did not understand the request because it was malformed.

    {"error"=>["Must supply role data"]}

Any ideas?

What type of Chef Server? Can you paste the debug output please?

It's enterprise chef and I don't get error messages by using @role.error_messages for some reason.

The above is as much verbosity as I get. Are there any arguments I can pass to the gem to get a more verbose output?

@samdunne how are you setting up the connection?

With a file like this:

ChefAPI.configure do |config|
  config.endpoint = 'https://addresstoserver.com/organizations/org'

  config.flavor = :enterprise

  config.client = 'samdunne'
  config.key    = '/etc/chef/client.pem'
  config.ssl_verify = false
end

I'm requiring the file where I need it. I can read information from chef server fine. But I just can't save it back. I have the permissions to save also

Set this:

config.log_level = :debug

Can you post @role.inspect and @role.to_json?

Inspect:

[4] pry(main)> @role.inspect
=> "#<Resource::Role name: \"test_role\", description: \"\", default_attributes: {\"removed\"}, override_attributes: {}, run_list: [\"removed\"], env_run_lists: {\"acceptance\"=>[\"removed\"]}>"

JSON:

"{\"name\":\"test_role\",\"description\":\"\",\"default_attributes\":{\"removed\"},\"override_attributes\":{},\"run_list\":[removed],\"env_run_lists\":{\"acceptance\":[removed]}}"

@samdunne I'm having trouble reproducing:

[1] pry(main)> ChefAPI.configure do |config|
[1] pry(main)*   config.endpoint = "https://api.opscode.com/organizations/sethvargo"
[1] pry(main)*   config.client = "sethvargo"
[1] pry(main)*   config.key = "~/.chef/sethvargo.pem"
[1] pry(main)* end
=> "~/.chef/sethvargo.pem"
[2] pry(main)> r = ChefAPI::Resource::Role.all.last
=> #<Resource::Role name: "testing", description: "This is a test node", default_attributes: {}, override_attributes: {}, run_list: [], env_run_lists: {}>
[3] pry(main)> r.save!
=> true

@samdunne wait... Can you show:

@role.default_attributes

please?

Is that set to JSON or a hash? In the default attributes you showed me, the value was:

default_attributes: {\"removed\"}

which is not a valid hash, so I'm confused...

Sorry I just removed all sensitive information from it. I kept it more together in the above gist.

The output of @role.default_attributes is what I've given you above.

What if you call role.save? Sorry for so much back-and-forth. I can't reproduce this, so yea :/

Debugging is all about back-and-forth ;). And the following gist:
https://gist.github.com/samdunne/75c8b72d8ecb42e78081

I had to (again) remove some information, sorry if it's making it more awkward :/

These lines are suspicious to me:

             ChefAPI::Connection | ===> PUT roles/feeds_app_mcollective_test...
             ChefAPI::Connection |      Chef flavor: :enterprise
             ChefAPI::Connection | ===> Building URI...
             ChefAPI::Connection |      Detected URI is relative
             ChefAPI::Connection |      Appending roles/test_role to https://inhouseserverr.com/organizations/bacon

Did you change any of that output? If not, I'm unsure why it's PUTing to roles/feeds_app_mcollective_test and not test_role.

Yeah I meant to change that name :/. Assume it's test_role

Can you try the same query against hosted chef (not your internal enterprise install)?

Seemed to work. Hmmmm. If the chef server api has changed in the last year perhaps it's a version mismatch?

@samdunne are you definitely running enterprise Chef? This sounds like a bad API in EC or OSC.

It's definitely enterprise yep. I'll try work around this myself and get back to you

@samdunne okay. What version of EC?

@sethvargo private chef 1.4.0 :/

Yea. I'm not sure I support that. Now that I don't work for Chef, I don't even have access to a build.

@samdunne I'm not really sure what to do with this issue... I can't reproduce, and I don't have a way to test support with Private Chef 1.4.

I'm leaning towards not supporting Private Chef 1.4 and close it as a won't fix :P