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?
Created attachment 1271536 [details] My work around using options as locks on ServiceTemplateProvisionRequests
Created attachment 1271865 [details] My work around using options as locks on ServiceTemplateProvisionRequests Fixed some bugs in my original solution.
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'`
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
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 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.
No requestee for needinfo set, can you take a look and determine where this should go?
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!”
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days