Hello Christian,
thank you for reporting the issue. Attached hammer logs show that the error occurs on the server side. May I ask you to attach relevant part of foreman logs too?
If you try to perform the same action in the UI, does it fail with the same error?

Most likely introduced with https://github.com/theforeman/foreman/pull/4146/
oVirt is probably affected too.

Tomas, why do you think it was introduced by the linked PR? According to the trace, it seems that compute_attrs for a given VM are nil. Based on incoming parameters, they are part of API request. I don't see how attributes can become nil so far

Parameters: {"host"=>{"environment_id"=>20, "compute_attributes"=>{"volumes_attributes"=>{}}, "host_parameters_attributes"=>{}, "interfaces_attributes"=>{}}, "apiv"=>"v2", "id"=>"119"}

Marek, the issue has actually been there even before the commit I mentioned, but this change eventually exposed the buggy code to users:
https://github.com/theforeman/foreman/pull/4146/files#diff-4443c0de1e4e867a30d3c878b9cb64e9R24

Before that it wasn't possible to update attribute of existing VMs on vmWare. From the traceback, the process fails on:
https://github.com/theforeman/foreman/blob/c952c782adac290fd5a1145090380424665f5fe1/app/models/compute_resources/foreman/model/vmware.rb#L434
(please note that the bug was reported against the foreman 1.15 and line numbers have been shifted since then)

So the issue isn't caused by compute_attributes being nil, but by volume attributes that can't be found. The code isn't prepared for partial updates and always requires the full set of compute attributes (including volumes and nics). The reason it works in the UI is that the host edit form pre-loads current compute attributes and therefore the attributes are complete.

Hi, we recently updated foreman to 1.15.6
And still seeing the same issue
is there a solution for this issue?

Bhanu

Im not using hammer, but the workaround I use when using the API is to first do a GET to get the nodes 'vm_compute_attributes' and then attach that result to my PUT operation on the node.

In perl (just to get the idea):

  my $client = REST::Client->new();

  $client->setHost($foreman_host);

  # Get compute attributes, bug workaround: 
  # http://projects.theforeman.org/issues/19990
  $client->GET("/api/hosts/$fqdn/vm_compute_attributes", $headers);

  my $compute_attrs = decode_json($client->responseContent());
  # Set the attributes for a new host
  my %json_data = (
    host => {
      comment => "Updating the comment attribute",
      compute_attributes => $compute_attrs,
    }
  );

  # Translate the perl hash in json notation
  my $data = encode_json(\%json_data);

  # Update parameter
  $client->PUT("/api/hosts/$fqdn",($data,$headers));

I'm not using hammer though...

Forgot to mention that it appears the UI is passing the parameter "sizeGb" to specify volume size. It appear the older, non-React UI code still uses that parameter, but the newer view code does not...maybe...

Steven Miller wrote:

The patch I submitted is the only way we could foreman to work. The hard drive size is still set correctly, even with this line completely commented out. I have a more sophisticated patch that will check if size_gb is set, and if it is not, then just skip the assignment (line 457 in the example).

In our 1.16 install, the "size_gb" parameter is never passed through the web interface, and seems to break at this line. I've attached "foremanpost-smiller-20180119.txt", which contains all the POSTed variables from a web browser doing a VMware deployment (on a 1.16 install). I see that both "size" and "SizeGB" are set within the host[compute_attributes][scsi_controllers] attribute. I don't see a size_gb set on the UI end at least.

I was also hitting the same error when attempting to provision a VMware VM. Moreover, my VMs were created and right away deleted via foreman. By commenting these lines out, I was able to create VMs via Foreman