Bug 1107705

Summary: vmWare Compute Resources not being honored
Product: Red Hat Satellite Reporter: Bryan Kearney <bkearney>
Component: ProvisioningAssignee: Dominic Cleal <dcleal>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Hutař <jhutar>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.3CC: bbuckingham, jmontleo, sthirugn, sudo, tkolhar
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/5652
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-11 12:24:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bryan Kearney 2014-06-10 12:54:24 UTC
Description

Steps to reproduce:
Create a VMware compute resource
Create a compute profile without thin provisioning checked
Save
Open compute profile again
Expected results:
when I open the compute profile, thin provisioning should not be checked
When I create a new host based on the compute profile, thin provisioning should not be checked
Actual results:
when I open the compute profile, thin provisioning is checked.
When I create a new host based on the compute profile, thin provisioning is checked

----

This behavior is seen accross most resources, NIC type, SCSI controller

The strange thing is that according to the production.log it seems we are actually changing the parameters:

Started PUT "/compute_profiles/5-redhat-6/compute_attributes/3" for 10.135.76.203 at 2014-05-09 13:31:14 -0500
Processing by ComputeAttributesController#update as */*
  Parameters: {"utf8"=>"â", "authenticity_token"=>"Ro9asdf62U4aOtUdm30G7asdghM7aW9asdfCZU/2Klbdf0573AavM=", "compute_attribute"=>{"vm_attrs"=>{"cpus"=>"1", "corespersocket"=>"1", "memory_mb"=>"1024", "cluster"=>"Cluster-A", "path"=>"/Datacenters/Cluster-A/vm", "guest_id"=>"rhel6_64Guest", "interfaces_attributes"=>{"new_interfaces"=>{"type"=>"VirtualE1000", "network"=>"network-1615", "_delete"=>""}, "0"=>{"type"=>"VirtualVmxnet3", "network"=>"network-109344", "_delete"=>""}}, "volumes_attributes"=>{"new_volumes"=>{"datastore"=>"esxhostA:Storage", "name"=>"Hard disk", "size_gb"=>"10", "thin"=>"true", "_delete"=>""}, "0"=>{"datastore"=>"esxhostA:Storage", "name"=>"Hard disk", "size_gb"=>"10", "thin"=>"false", "_delete"=>""}}, "scsi_controller_type"=>"ParaVirtualSCSIController", "image_id"=>"Templates/UNIX/RedHat/x86_64/6.5_x86_64"}}, "compute_profile_id"=>"5-redhat-6", "id"=>"3"}
Successfully decrypted field for Foreman::Model::Vmware vmware
Redirected to https://foremanhost.com/compute_profiles/5-redhat-6
Completed 302 Found in 66ms (ActiveRecord: 3.4ms)


This could be related to bug 4159

Comment 1 Bryan Kearney 2014-06-10 12:54:27 UTC
Created from redmine issue http://projects.theforeman.org/issues/5652

Comment 2 Bryan Kearney 2014-06-10 12:54:32 UTC
Upstream bug assigned to dcleal

Comment 4 Bryan Kearney 2014-06-10 14:27:43 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/5652 has been closed

Comment 7 Magnus Glantz 2014-08-07 12:54:44 UTC
I can verify that I also see this on RHN Sat 6.0.3, but not in Foreman Version 1.4.0.

Comment 8 Dominic Cleal 2014-08-07 13:02:03 UTC
(In reply to Magnus Glantz from comment #7)
> I can verify that I also see this on RHN Sat 6.0.3, but not in Foreman
> Version 1.4.0.

The fix will be shipped in Satellite 6 at GA (aka 6.0.4).

Comment 9 Magnus Glantz 2014-08-07 13:06:07 UTC
Fantastic, thanks for the feedback Dominic.

Comment 11 Bryan Kearney 2014-09-11 12:24:57 UTC
This was delivered with Satellite 6.0 which was released on 10 September 2014.