Description of problem: The naming method runs before the dialog is parsed. This makes it more difficult to set custom naming schemes for customers, especially when using objects like Tag Controls which the DialogParser/CatalogItemInitialization handles. The Naming method is run before the DialogParser runs in CatalogItemInitialization. It also looks to run in the context of miq_provision, rather than a service_template_provision_task which is what I would expect. The dialog options are missing. This is problematic for customers who wish to switch to the standard CatalogItemInitialization from the Generic method (build_vm_provision_request). The Generic method seems to continue to work. Similar problem in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1442225 Version-Release number of selected component (if applicable): 5.7.2.1 20170406142927_0a1ad0e How reproducible: 100% Steps to Reproduce: 1. Create Dialog with tag_0_my_option or option_0_my_option element 2. Create a Catalog, Catalog Item, and Associated previous dialog with the Catalog Item 3. Provision a VM 4. Inspect either prov.get_tags, prov.get_option(:dialog), or prov.get_option(:my_option) Actual results: Options or tags are not available (unless using prov.miq_request) because the DialogParser/CatalogItemInitialization method has not run yet. Expected results: prov.get_tags returns the results as set by DialogParser/CatalogItemInitialization prov.get_option(:my_option) returns the selected dialog value prov.get_tags[:my_option] returns the value selected in the dialog associated with tag_0_my_option Additional info: LOG FROM DEFAULT METHOD (No Modifications). This shows the miq_provision context (see top line): [----] I, [2017-05-23T20:32:28.595727 #2793:a8cb90] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod vmname> Detected vmdb_object_type:<miq_provision> [----] I, [2017-05-23T20:32:28.607959 #2793:a8cb90] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod vmname> vmname: "cfme$n{3}" [----] I, [2017-05-23T20:32:28.641502 #2793:a9b140] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod [/ManageIQ/Cloud/VM/Provisioning/Naming/vmname]> Ending [----] I, [2017-05-23T20:32:28.641879 #2793:a9b140] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) Method exited with rc=MIQ_OK The above was provisioned with tag_0_environment = 'test' set in a service dialog. As the /Cloud/VM/Provisioning/Naming/default should have set: # Returns the first 3 characters of the "environment" tag (or nil) def env_tag env = provision_object.get_tags[:environment] return env[0, 3] unless env.blank? end LOG FROM CUSTOM METHOD (Attempting to grab dialog options - notice they are missing): [----] I, [2017-05-23T19:41:57.268490 #2801:a8dcfc] INFO -- : Q-task_id([service_template_provision_request_1000000000010]) <AEMethod vm_name> My Company Automation: Inspecting provisioning object: #<MiqAeServiceManageIQ_Providers_Amazon_CloudManager_Provision:0xd7089bc @object=#<ManageIQ::Providers::Amazon::CloudManager::Provision id: 1000000000027, description: "Provision from [rhel7-image] to [cfme###]", state: "pending", request_type: "template", userid: "admin", options: {:initial_pass=>true, :service_template_request=>false, :miq_request_dialog_name=>"miq_provision_amazon_dialogs_template", :customize_enabled=>["enabled"], :requester_enabled=>["disabled"], :purpose_enabled=>["disabled"], :current_tab_key=>:schedule, :owner_phone=>nil, :owner_country=>nil, :owner_phone_mobile=>nil, :owner_title=>nil, :owner_first_name=>nil, :owner_manager=>nil, :owner_address=>nil, :owner_company=>nil, :owner_last_name=>nil, :owner_manager_mail=>nil, :owner_city=>nil, :owner_department=>nil, :owner_load_ldap=>nil, :owner_manager_phone=>nil, :owner_state=>nil, :owner_office=>nil, :owner_zip=>nil, :owner_email=>nil, :request_notes=>nil, :vm_tags=>[], :placement_auto=>[true, 1], :placement_availability_zone=>[nil, nil], :cloud_network=>[nil, nil], :cloud_subnet=>[nil, nil], :security_groups=>[nil, nil], :floating_ip_address=>[nil, nil], :number_of_vms=>[1, "1"], :vm_description=>nil, :vm_prefix=>nil, :src_vm_id=>[1000000000001, "rhel7-image"], :vm_name=>"changeme", :schedule_type=>["immediately", "Immediately on Approval"], :schedule_time=>Wed, 24 May 2017 22:39:00 UTC +00:00, :retirement=>[0, "Indefinite"], :retirement_warn=>[604800, "1 Week"], :instance_type=>[1000000000001, "t2.nano: T2 Nano"], :guest_access_key_pair=>[1000000000002, "key_pair_gitlab"], :monitoring=>["basic", "Basic"], :dns_servers=>nil, :dns_suffixes=>nil, :addr_mode=>["dhcp", "DHCP"], :linux_host_name=>nil, :gateway=>nil, :linux_domain_name=>nil, :subnet_mask=>nil, :customization_template_script=>nil, :root_password=>nil, :hostname=>nil, :start_date=>"5/24/2017", :start_hour=>"22", :start_min=>"39", :name=>"Test", :description=>"Test", :long_description=>nil, :provision_cost=>nil, :display=>true, :catalog_id=>"1000000000001", :st_prov_type=>"amazon", :available_catalogs=>[["XOM", 1000000000001]], :retire_fqname=>"/Service/Retirement/StateMachines/ServiceRetirement/Default", :reconfigure_fqname=>nil, :fqname=>"/Service/Provisioning/StateMachines/ServiceProvision_Template/CatalogItemInitialization", :available_dialogs=>{1000000000001=>"azure-single-vm-from-user-image", 1000000000002=>"DeploySplunkServerRHV"}, :service_type=>"atomic", :dialog_id=>"1000000000002", :src_vm_nics=>[], :src_vm_lans=>[], :src_ems_id=>[1000000000001, "AWS"], :requester_group=>"EvmGroup-super_administrator", :delivered_on=>nil, :pass=>0, :miq_force_unique_name=>[true, 1], :service_guid=>"665ac1b6-4011-11e7-925c-000c29136a02", :service_resource_id=>1000000000001, :owner_group=>"EvmGroup-super_administrator", :dns_domain=>nil}, created_on: "2017-05-23 23:41:53", updated_on: "2017-05-23 23:41:53", message: "VM Provisioning - Request Created", status: "Ok", type: "ManageIQ::Providers::Amazon::CloudManager::Provisi...", miq_request_id: 1000000000010, source_id: 1000000000001, source_type: "VmOrTemplate", destination_id: nil, destination_type: nil, miq_request_task_id: nil, phase: nil, phase_context: {}, tenant_id: 1000000000001>, @virtual_columns=["placement_auto", "provision_type", "region_description", "region_number"], @associations=["destination", "eligible_availability_zones", "eligible_cloud_networks", "eligible_cloud_subnets", "eligible_cloud_tenants", "eligible_clusters", "eligible_customization_templates", "eligible_floating_ip_addresses", "eligible_folders", "eligible_guest_access_key_pairs", "eligible_hosts", "eligible_instance_types", "eligible_iso_images", "eligible_pxe_images", "eligible_pxe_servers", "eligible_resource_pools", "eligible_security_groups", "eligible_storages", "eligible_windows_images", "miq_provision_request", "miq_request", "miq_request_task", "miq_request_tasks", "source", "tenant", "vm", "vm_template"]> Notice that the dialog options aren't available via this object. We can get them from prov.miq_request, but this seems very kludgy considering our DialogParser should have set the appropriate options. ALSO FROM LOG: [----] W, [2017-05-23T19:41:57.288568 #2801:a8dcfc] WARN -- : Q-task_id([service_template_provision_request_1000000000010]) <AEMethod vm_name> My Company Automation: [Unable to find options] Options are being populated by the following: # ensure we are using this method in the proper context case $evm.root['vmdb_object_type'] when 'miq_provision', 'miq_provision_request', 'miq_provision_request_template' prov = $evm.root['miq_provision_request'] || $evm.root['miq_provision'] || $evm.root['miq_provision_request_template'] options = prov.get_option(:dialog) else raise "Invalid $evm.root['vmdb_object_type']: #{$evm.root['vmdb_object_type']}" end
Hey Chris, I'm not trying to be combative here, but I fail to see how this is considerd a 'FutureFeature'/'RFE' when clearly the out-of-the-box tagging with Naming does not work. See additional details above: LOG FROM DEFAULT METHOD (No Modifications). This shows the miq_provision context (see top line): [----] I, [2017-05-23T20:32:28.595727 #2793:a8cb90] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod vmname> Detected vmdb_object_type:<miq_provision> [----] I, [2017-05-23T20:32:28.607959 #2793:a8cb90] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod vmname> vmname: "cfme$n{3}" [----] I, [2017-05-23T20:32:28.641502 #2793:a9b140] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) <AEMethod [/ManageIQ/Cloud/VM/Provisioning/Naming/vmname]> Ending [----] I, [2017-05-23T20:32:28.641879 #2793:a9b140] INFO -- : Q-task_id([service_template_provision_request_1000000000015]) Method exited with rc=MIQ_OK The above was provisioned with tag_0_environment = 'test' set in a service dialog. As the /Cloud/VM/Provisioning/Naming/default should have set: # Returns the first 3 characters of the "environment" tag (or nil) def env_tag env = provision_object.get_tags[:environment] return env[0, 3] unless env.blank? end An out-of-the-box provision, with a service dialog option of tag_0_environment, should yield a vm name of: Expected: testcfme01 Actual: cfme01 As per line 52 of the standard /Infrastructure/VM/Provisioning/Naming/vmname method: env = provision_object.get_tags[:environment] Clearly, this will return nothing every time unless the DialogParser has run, as tags are not available until DialogParser has been run. Just some food for thought here. Thanks! -Dustin
Dustin - The simple answer is that the logic you are referring to was designed to work with Lifecycle provisioning before services existed. It needs to be enhanced to work within the service construct without break the existing Lifecycle provisioning implementations. I researched this issue and it is not a straight-forward fix. It still needs to be determined if this can be done in a backwards compatible way and if not what would be the least impactful on existing users.
Greg, That does make sense. Thank you for the feedback! I might suggest that we take the example Naming with tags out of our Naming automate method, until we get this RFE put into place, unless this will truly be implemented by 5.7.4. This might take some of the confusion out of the method. Much appreciated! -Dustin
Service Catalog Bundles are also affected by this. Part of the fix needs to be that each Catalog Item that is part of a bundle can reference the correct dialog options. For example a Service Catalog Bundle that has two VMware Catalog Items. The VM name needs to include an attribute such as appcode. The Service Dialog has been built with two elements for the appcode with the sequence number in the name (e.g. tag_1_appcode and tag_2_appcode). When the vmname method for the first catalog item is called it should use the value from tag_1_appcode and when called for the second catalog item it should use the value from tag_2_appcode.
I am working on get this enhancement code change into 5.8.3 but wanted to note that any fix other then the latest release is going to be partial. Meaning we can expose a method for automate that can be called, but we are not planning on changing the out-of-the-box automate modeling on older versions. Fully implementing the change at the model level would be for the user to decided.
https://github.com/ManageIQ/manageiq/pull/16897
https://github.com/ManageIQ/manageiq-automation_engine/pull/153
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/1b85d4a1c435a2e28235a3fb65e609b6d372586c commit 1b85d4a1c435a2e28235a3fb65e609b6d372586c Author: Greg McCullough <gmccullo> AuthorDate: Wed Jan 24 17:56:33 2018 -0500 Commit: Greg McCullough <gmccullo> CommitDate: Fri Jan 26 16:46:42 2018 -0500 Refactor Provision task naming to allow for calls from automate. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1455002 app/models/miq_provision.rb | 13 ++++++++----- app/models/miq_provision/automate.rb | 14 ++++++++++++++ app/models/miq_provision/naming.rb | 8 +------- app/models/miq_provision_request.rb | 6 +++++- 4 files changed, 28 insertions(+), 13 deletions(-)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/0818e1588d8653cec53ca4c7e4dc67de18125854 commit 0818e1588d8653cec53ca4c7e4dc67de18125854 Author: Greg McCullough <gmccullo> AuthorDate: Wed Jan 24 18:10:07 2018 -0500 Commit: Greg McCullough <gmccullo> CommitDate: Fri Jan 26 16:48:09 2018 -0500 Support vm_name enumerations and request description updates https://bugzilla.redhat.com/show_bug.cgi?id=1455002 app/models/miq_provision.rb | 4 +++- spec/models/miq_provision_spec.rb | 39 +++++++++++++++++++++++++++++++++++---- 2 files changed, 38 insertions(+), 5 deletions(-)
Moving back on ON_DEV until https://github.com/ManageIQ/manageiq-automation_engine/pull/153 is merged.
New commit detected on ManageIQ/manageiq-automation_engine/master: https://github.com/ManageIQ/manageiq-automation_engine/commit/b9c599d5bfb5022dc2cb535b83ca1d54c60b0c5a commit b9c599d5bfb5022dc2cb535b83ca1d54c60b0c5a Author: Greg McCullough <gmccullo> AuthorDate: Fri Jan 26 15:27:55 2018 -0500 Commit: Greg McCullough <gmccullo> CommitDate: Fri Jan 26 15:27:55 2018 -0500 Support calling update_vm_name for miq_provision service models https://bugzilla.redhat.com/show_bug.cgi?id=1455002 lib/miq_automation_engine/service_models/miq_ae_service_miq_provision.rb | 1 + 1 file changed, 1 insertion(+)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/ad1e960d127cc738e4e0d23eba4315b201595f7c commit ad1e960d127cc738e4e0d23eba4315b201595f7c Author: Greg McCullough <gmccullo> AuthorDate: Fri Feb 2 12:18:06 2018 -0500 Commit: Greg McCullough <gmccullo> CommitDate: Mon Feb 5 10:47:26 2018 -0500 Follow up to update_vm_name for Service template provisioning https://bugzilla.redhat.com/show_bug.cgi?id=1455002 app/models/miq_provision.rb | 2 +- spec/models/miq_provision_spec.rb | 11 +++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-)