Bug 1442225

Summary: [RFE]: Support unique vm naming from automate when provisioning service with multiple VMs
Product: Red Hat CloudForms Management Engine Reporter: Ian Tewksbury <itewksbu>
Component: AutomateAssignee: John Hardy <jhardy>
Status: CLOSED WONTFIX QA Contact: Dave Johnson <dajohnso>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.7.0CC: cbolz, dajohnso, itewksbu, jhardy, jocarter, mfeifer, mkanoor, obarenbo, sacpatil, tfitzger, vestival
Target Milestone: GAKeywords: FutureFeature
Target Release: cfme-futureFlags: itewksbu: needinfo+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ec2:provision:automate
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-18 13:28:24 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:
Bug Depends On:    
Bug Blocks: 1503797    
Attachments:
Description Flags
My work around using options as locks on ServiceTemplateProvisionRequests
none
My work around using options as locks on ServiceTemplateProvisionRequests
none
Service/Provisioning/StateMachines/Methods/set_vm_names: work around using options as locks on ServiceTemplateProvisionRequests none

Description Ian Tewksbury 2017-04-13 19:50:40 UTC 
Description of problem:
When provisioning a service the `vmname` method is called before the dialog options are ever parsed. This means that I as a custom service dialog creator can not create a dialog field with a `vm_prefix` field and have it fed into the `vmname` method to then have unique VM names created assuming my service catalog item also allows the user to set the number of VMs to create.

This then leaves it on the Automate writer to roll their own logic for avoiding name conflicts. At first glance this looks simple, check VMDB for used names, start counting from there. But the problem gets very difficult as soon as you have multiple services requests going on at the same time all using the same vm_prefix. Then you need some way for multi threaded processes to be pulling unique names from a pull of names. All of which it seems `vmname` handles, but there is no way to leverage that handy logic from within automate after the dilog options have been parsed to determine the vm prefix.


Version-Release number of selected component (if applicable):
All of them.


How reproducible:
Always.


Expected results:
Ideally i would be able to set `vm_prefix` in custom service dialog and the out of the box automate would take care of it from there. If that isn't possible, at least having some function or method or something that can be called from automate to get unique VM names based on a prefix, that is thread safe when there are multiple service provisioning going on at the same time.


Additional info:
I have attached a copy of the solution I came up with to work around this using options on ServiceTemplateProvisionRequests that act as locks. It isn't pretty but it seems to work. Maybe helpful for whoever digs into a solution for this?
Comment 2 Ian Tewksbury 2017-04-13 20:04:49 UTC 
Created attachment 1271536 [details]
My work around using options as locks on ServiceTemplateProvisionRequests
Comment 3 Ian Tewksbury 2017-04-16 13:14:03 UTC 
Created attachment 1271865 [details]
My work around using options as locks on ServiceTemplateProvisionRequests

Fixed some bugs in my original solution.
Comment 4 Ian Tewksbury 2017-05-15 12:00:46 UTC 
Created attachment 1278947 [details]
Service/Provisioning/StateMachines/Methods/set_vm_names: work around using options as locks on ServiceTemplateProvisionRequests

Updated `set_vm_names` method to turn off debugging and remove unnecissary `require 'set'`
Comment 9 Ian Tewksbury 2017-09-05 12:27:34 UTC 
For anyone looking for this feature until such time as it is in the upstream MIQ project, an MIQ domain has been created with a method that can accomplish this. This domain, and specifically this feature, is being used in production at at least one CloudForms customer.

Domain: https://github.com/rhtconsulting/miq-Utilities
Specific Method: https://github.com/rhtconsulting/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/Naming.class/__methods__/set_vm_names.rb

The method is intended to be inserted as a step in a Service provisioning state machine.

Any questions or issues about the domain can be brought up on the projects GitHub.

Blue skies,
Ian
Comment 13 Ian Tewksbury 2017-09-08 00:57:12 UTC 
Support found an issue with the set_vm_names.rb method. I have updated the upstream miq-Utilities project to fix the bug.

For anyone looking for a work around to this RFE until an official fix is in place see, https://github.com/rhtconsulting/miq-Utilities/releases/tag/v3.1
Comment 14 Ian Tewksbury 2017-09-08 00:58:06 UTC 
Comment on attachment 1278947 [details]
Service/Provisioning/StateMachines/Methods/set_vm_names: work around using options as locks on ServiceTemplateProvisionRequests

THis is out of date. See https://github.com/rhtconsulting/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/Naming.class/__methods__/set_vm_names.rb for the latest.
Comment 17 Dave Johnson 2018-06-10 01:48:11 UTC 
No requestee for needinfo set, can you take a look and determine where this should go?
Comment 18 Dave Johnson 2018-06-10 02:22:20 UTC 
No requestee for needinfo set, can you take a look and determine where this should go?
Comment 19 Josh Carter 2018-09-18 13:28:24 UTC 
Dear customer, 

The CloudForms team is reviewing the current CloudForms RFE(Request for Enhancement) backlog in order to improve our responsiveness to customers. We are closing any requests for versions no longer within full support(link below to the lifecycle) or that do not have a clear spot on the product roadmap. We are committing to better management of the backlog as we move forward. If you have an RFE that you still have a strong business case for, please open a new BZ against the currently supported version 4.6.

Lifecycle page: https://access.redhat.com/support/policy/updates/cloudforms

If you have any concerns about this, please let us know.

Thanks and regards!”
Comment 20 Red Hat Bugzilla 2023-09-14 03:56:23 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days