Bug 1738472

Summary: [Kubevirt-Foreman] Host creation via API ignores CPUs count specified in request
Product: Red Hat Satellite Reporter: Vladimír Sedmík <vsedmik>
Component: Compute Resources - CNVAssignee: Shira Maximov <mshira>
Status: CLOSED ERRATA QA Contact: Vladimír Sedmík <vsedmik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.6.0CC: egolov, ehelms, mshira, orabin, zhunting
Target Milestone: 6.7.0Keywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: tfm-rubygem-foreman_kubevirt-0.1.5-1,tfm-rubygem-hammer_cli_foreman_kubevirt-0.1.4 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-14 13:25:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vladimír Sedmík 2019-08-07 09:17:21 UTC
Description of problem:
When creating a host on Satellite using API the host is created successfully, but always with one CPU only, regardless the core request specified in JSON.

Version-Release number of selected component (if applicable):
Satellite 6.6.0 snap 14:
satellite-6.6.0-5.beta
tfm-rubygem-foreman_kubevirt-0.1.4-1
tfm-rubygem-fog-kubevirt-1.3.1-1

How reproducible:
always

Steps to Reproduce:
1. Specify a JSON request file like the following one, update with appropriate org, loc and other ids, choose "cores" count > 1:
vim req.json
{ "location_id" : "2",
  "organization_id" : "1",
  "host" : {
    "name" : "test-api-4c",
    "location_id" : "2",
    "organization_id" : "1",
    "compute_resource_id" : "1",
    "provision_method" : "build",
    "compute_attributes" : {
      "cores" : "4",
      "memory": "1073741824",
      "volumes_attributes": {
        "0": { "storage_class": "gluster-default-volume", "capacity": "2" }
      }
    },
    "operatingsystem_id": "1",
    "architecture_id" : "1",
    "interfaces_attributes": {
      "0" : {
       	"domain_id" : "1",
       	"name" : "test-api-4c",
       	"ip": "172.16.0.108",
       	"subnet_id" : "1",
       	"mac" : "00:03:14:15:92:04",
        "managed" : "1",
        "primary" : "1",
        "provision" : "1",
        "type": "Nic::Managed",
        "virtual" : "0",
        "compute_attributes" : {
          "cni_provider" : "pod",
          "network" : "ovs-net-1"
        }
      }
    }
  }
}

2. curl -u admin:password -H "Content-Type: application/json" -X POST -d @req.json --insecure  https://<sat_fqdn>/api/hosts

3. Check the newly created host at the Satellite and OCP side.

Actual results:
The cores count is 1 regardless the value specified in JSON.

Expected results:
Cores count matching the value given in req.json file.

Additional info:
It is possible to create a host with more CPUs via UI successfully.
Tested against OCP v3.

Comment 3 Shira Maximov 2019-08-19 11:38:28 UTC
Changing this into documentation BZ, the correct way to send the cores in 'cpu_cores' 
I will change the documentation for this in hammer_cli_foreman_kubevirt and in foreman_kubevirt repositories.

Comment 4 Shira Maximov 2019-08-19 11:39:50 UTC
Created redmine issue https://projects.theforeman.org/issues/27655 from this bug

Comment 5 Bryan Kearney 2019-08-19 12:02:46 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27655 has been resolved.

Comment 11 errata-xmlrpc 2020-04-14 13:25:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1454