Bug 1300815 - Service Provisioning for one VM creates two VMs
Service Provisioning for one VM creates two VMs
Status: CLOSED NOTABUG
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
5.5.0
Unspecified Unspecified
unspecified Severity low
: GA
: 5.6.0
Assigned To: Tina Fitzgerald
Dave Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-21 14:35 EST by Jared Deubel
Modified: 2016-01-28 10:30 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-26 11:30:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
service screen shot (25.92 KB, image/png)
2016-01-25 12:00 EST, Tina Fitzgerald
no flags Details
Service screen shot. (23.27 KB, image/png)
2016-01-25 12:01 EST, Tina Fitzgerald
no flags Details
Service screen shot. (12.66 KB, image/png)
2016-01-25 12:02 EST, Tina Fitzgerald
no flags Details
Service screen shot. (67.45 KB, image/png)
2016-01-25 12:02 EST, Tina Fitzgerald
no flags Details
Service screen shot. (46.58 KB, image/png)
2016-01-25 12:03 EST, Tina Fitzgerald
no flags Details

  None (edit)
Description Jared Deubel 2016-01-21 14:35:39 EST
Description of problem:

I got 2 VMs created in this service named "testlongname" and "test_0043".  "testlongname" has correct number of CPUs and Memory, "test_0043" has wrong number of both. Not sure why the test_0043 VM is being created.


Version-Release number of selected component (if applicable):
5.5

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Jared Deubel 2016-01-21 14:37 EST
Created attachment 1116990 [details]
evm logs
Comment 4 Tina Fitzgerald 2016-01-25 12:00 EST
Created attachment 1118122 [details]
service screen shot
Comment 5 Tina Fitzgerald 2016-01-25 12:01 EST
Created attachment 1118123 [details]
Service screen shot.
Comment 6 Tina Fitzgerald 2016-01-25 12:02 EST
Created attachment 1118124 [details]
Service screen shot.
Comment 7 Tina Fitzgerald 2016-01-25 12:02 EST
Created attachment 1118126 [details]
Service screen shot.
Comment 8 Tina Fitzgerald 2016-01-25 12:03 EST
Created attachment 1118127 [details]
Service screen shot.
Comment 9 Tina Fitzgerald 2016-01-25 12:28:25 EST
Hi Jared,

Multiple VMs are being created from a single service item due to the way it's configured.

I've attached the screen shots Rich provided showing the service item.

1. The attachment containing Image 4 shows the entry point for the service as:
/Service/Provisioning/StateMachines/ServiceProvision_Template/VMWare_Build_VMProvisionRequest
This entrypoint is intended to be used with a generic service catalog item that provisions one or many VMs into a service

2. The attachment for the screen shot containing Image 5 shows the service item type as vmware.  (the dialogs are not present for a generic item)

So, basically, the service provision generated a vm provision request from the options passed to the VMWare_Build_VMProvisionRequest method, and another as specified in the vmware dialogs.

There is no way to convert the service item from vmware to generic, so the customer should delete the service item, and create the item again as a generic service item.
 
Please let me know if you have any questions.

Thanks,
Tina
Comment 10 Tina Fitzgerald 2016-01-26 11:30:55 EST
Customer confirmed configuration change resolved the issue:
.....
Most recent comment: On 2016-01-26 10:24:32, Caldwell, Rich commented:
"That was the issue. I was not aware of the purpose of the Generic service item. Considering I wanted to build VMWare VMs, I chose the VMWare service item type.  Thanks for the clarification. It is now working properly once I built a new catalog item based on the proper service item type.  This case can be closed.

Note You need to log in before you can comment on or make changes to this bug.