Bug 1379476 - Service : GCE service catalog request fails because of VM name regex constraint
Summary: Service : GCE service catalog request fails because of VM name regex constraint
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.8.0
Assignee: Lucy Fu
QA Contact: Shveta
URL:
Whiteboard: service:google
Depends On:
Blocks: 1384204 1384206
TreeView+ depends on / blocked
 
Reported: 2016-09-26 22:13 UTC by Shveta
Modified: 2017-06-12 17:47 UTC (History)
4 users (show)

Fixed In Version: 5.8.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1384204 1384206 (view as bug list)
Environment:
Last Closed: 2017-06-12 17:47:38 UTC
Category: ---
Cloudforms Team: GCE
Target Upstream Version:


Attachments (Terms of Use)

Description Shveta 2016-09-26 22:13:56 UTC
Description of problem:


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

How reproducible:


Steps to Reproduce:
1. Create a service catalog for type gce
2. i gave the instance name to be testgcevm
3. The instance name was auto assigned value testgcevm_001
4. the request failed with error : " Q-task_id([miq_provision_6]) In State=[CheckProvisioned], invoking [on_error] method=[update_provision_status(status => '[Fog::Errors::Error]: Invalid value for field 'resource.name': 'testgcevm_0001'. Must be a match of regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)'')]
"


Actual results:


Expected results:


Additional info:


INFO -- : Q-task_id([miq_provision_6]) Processed  State=[CheckProvisioned] with Result=[error]
[----] W, [2016-09-26T18:05:13.182367 #4405:1191990]  WARN -- : Q-task_id([miq_provision_6]) Error in State=[CheckProvisioned]
[----] I, [2016-09-26T18:05:13.182783 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) In State=[CheckProvisioned], invoking [on_error] method=[update_provision_status(status => '[Fog::Errors::Error]: Invalid value for field 'resource.name': 'testgcevm_0001'. Must be a match of regex '(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)'')]
[----] I, [2016-09-26T18:05:13.187631 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) Updated namespace [Cloud/VM/Provisioning/StateMachines/VMProvision_vm/update_provision_status  ManageIQ/Cloud/VM/Provisioning/StateMachines]
[----] I, [2016-09-26T18:05:13.200677 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) Invoking [inline] method [/ManageIQ/Cloud/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status] with inputs [{"status"=>"[Fog::Errors::Error]: Invalid value for field "}]
[----] I, [2016-09-26T18:05:13.201566 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) <AEMethod [/ManageIQ/Cloud/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status]> Starting 
[----] I, [2016-09-26T18:05:14.074728 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) <AEMethod [/ManageIQ/Cloud/VM/Provisioning/StateMachines/VMProvision_VM/update_provision_status]> Ending
[----] I, [2016-09-26T18:05:14.074914 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) Method exited with rc=MIQ_OK
[----] I, [2016-09-26T18:05:14.076030 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) Followed  Relationship [miqaedb:/Cloud/VM/Provisioning/StateMachines/VMProvision_vm/template#create]
[----] I, [2016-09-26T18:05:14.076881 #4405:1191990]  INFO -- : Q-task_id([miq_provision_6]) Followed  Relationship [miqaedb:/cloud/VM/Lifecycle/Provisioning#create]

Comment 2 Greg McCullough 2016-09-29 17:21:43 UTC
Discussed with Brad and we agreed to stop appending the "_" character as part of the enforced service naming here:

https://github.com/ManageIQ/manageiq/blob/be84eaba93ad8c621bdff9cdfb3f4be07cea9e38/app/models/miq_provision/naming.rb#L32


This change could cause issues for existing deployments that rely on this naming so we do not want to back-port this change to 5.6, but will introduce it as part of 5.7 release as part of the release notes.

For 5.6 users that need to avoid this issue there is a work-around:
When defining the service_template and setting the "Instance Name" on the Catalog tab (for example "testgcevm" was used in this bug) you should also include the unique naming pattern which the service processing will honor and not try to append the default one which is "_$n{4}".
In this case the "Instance Name" would be changed to "testgcevm$n{4}".  This works today without any code changes.


5.7 users and above would need to do the opposite, once this change is introduced, but only if keeping the naming convention is important to them.

In this case, if you were provisioning to a provider that supported the underscore character you will want to include it as part of the naming of the Instance/VM.  You would add the "_" to the existing name and allow the service processing to add the unique naming pattern "$n{4}" or append the entire value.

Again using the name provided in this example either value should restore the previous naming pattern:
"testgcevm_"
or
"testgcevm_$n{4}"

Comment 4 CFME Bot 2016-10-06 16:11:07 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/b4f4ed9f8032b02b9c7eaa18c27836530b36964b

commit b4f4ed9f8032b02b9c7eaa18c27836530b36964b
Author:     Lucy Fu <lufu>
AuthorDate: Thu Oct 6 08:51:36 2016 -0400
Commit:     Lucy Fu <lufu>
CommitDate: Thu Oct 6 11:05:50 2016 -0400

    Stop appending the "_" character as part of the enforced VM naming.
    
    Some providers don't allow the "_" character in the VM name.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1379476

 app/models/miq_provision/naming.rb                      |  1 -
 .../providers/vmware/infra_manager/provision_spec.rb    | 17 +++++++++++++++++
 spec/models/miq_provision_request_template_spec.rb      |  4 ++--
 3 files changed, 19 insertions(+), 3 deletions(-)

Comment 7 Shveta 2017-03-03 00:50:50 UTC
Vm name auto assigned does not contain special chars anymore.
Verified in 5.8.0.2-nightly.20170228141623_8710eed


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