| Summary: | vsphere deployables fail to start.. RbVmomi::Fault:InvalidRequest: Error formatting number | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> |
| Component: | deltacloud-core | Assignee: | Michal Fojtik <mfojtik> |
| Status: | CLOSED ERRATA | QA Contact: | Aziza Karol <akarol> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | akarol, cpelland, dajohnso, deltacloud-maint, dgao, jprovazn, lutter, matt.wagner, mfojtik, morazi, rananda, ssachdev |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-15 20:28:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
wes hayutin
2011-10-05 19:50:41 UTC
For Vsphere I'm not able to add a entry for storage and have the hwp match.. so I'm kind of stuck The issue is that conductor passes in '1.0' for hwp_cpu where RbVmomi wants an integer, i.e. '1' Filed https://issues.apache.org/jira/browse/DTACLOUD-86 against DC to make sure we do better validation of hwp_cpu in DC and produce a better error message I've spent a bit trying to reproduce this bug or find where it's happening on the Conductor side to no avail. If you hit a reproducer, can you let me (or one of my compatriots) know and set us up with access? The problem is on conductor side:
if backend hw profile property is of type 'range', let's say 1-4 and frontend end hw profile property is matched in this range, but is of type float ('1.0'), this float value is not converted to integer but is passed as float to dc api
About the 'hwp_storage': This parameter could be safely ignored since DC is not processing it. In VSphere you can't define custom storage size. Storage is 'inherited' from the template you're using for clone. Anyway my 50cents for removing this parameter completely (it's better to *not* send it when it's blank). (In reply to comment #3) > Filed https://issues.apache.org/jira/browse/DTACLOUD-86 against DC to make sure > we do better validation of hwp_cpu in DC and produce a better error message http://mail-archives.apache.org/mod_mbox/incubator-deltacloud-dev/201110.mbox/%3C1317900479-98208-1-git-send-email-mfojtik@redhat.com%3E For Conductor, I've posted https://fedorahosted.org/pipermail/aeolus-devel/2011-October/005446.html which should keep us from sending these values in the first place. (At least in this specific case.) Whoops, I failed to update this. Fixed with this commit:
commit 1f3f5f1e81d5964d1251bba51d42b639b692a1ae
Author: Matt Wagner <matt.wagner>
Date: Thu Oct 6 11:23:29 2011 -0400
generate_override_property_value returns integers for ranged values
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=743718
Vsphere deployables started successfully even if the hwp_cpu value is float.
I changed the hwp_cpu value to 1.0 and deployment was successful without any error.
This float value is converted to integer and is passed to dc api.
[root@dell-pe1950-01 ~]# deltacloudd -i mock -p 3002 -V
Processing /api/instances (for 127.0.0.1 at Wed Nov 02 05:03:00 -0400 2011) [POST] [VSphere]
Parameters: {"name"=>"vmware4-vmware", "image_id"=>"factory-image-d7acd937-a3ec-4abd-9178-10341ae2c945", "realm_id"=>"datastore1", "hwp_memory"=>"512", "keyname"=>"", "hwp_id"=>"default", "hwp_cpu"=>"1", "hwp_storage"=>"", "user_data"=>""}
Provider: 10.16.120.136
Authentication: Basic
Server: thin 1.2.11 codename Bat-Shit Crazy
Accept: application/xml
verified on:
[root@dell-pe1950-01 ~]# rpm -qa | grep aeolus
aeolus-conductor-0.6.0-0.20111029030732git7410602.el6.noarch
rubygem-ZenTest-4.3.3-2.aeolus.el6.noarch
aeolus-all-0.6.0-0.20111029030732git7410602.el6.noarch
rubygem-aeolus-cli-0.1.0-3.20111028152758git7063136.el6.noarch
rubygem-aeolus-image-0.1.0-4.20111024205454git6b2b696.el6.noarch
aeolus-conductor-daemons-0.6.0-0.20111029030732git7410602.el6.noarch
aeolus-configure-2.3.0-0.20111028220920gitf01b051.el6.noarch
rubygem-rack-mount-0.7.1-3.aeolus.el6.noarch
aeolus-conductor-doc-0.6.0-0.20111029030732git7410602.el6.noarch
rubygem-arel-2.0.10-0.aeolus.el6.noarch
Please don't use Float as CPU property. In newer version of Deltacloud API (starting from 0.4.1) we're doing a more strict validation of parameters and using Float for 'hwp_cpu' will lead to validation error (DC will return code '400'). Hi Michal, Indeed, the use of a float was a bug. My patch fixed it up to use an integer. (Although it's already in 'verified' state, I'm re-assigning this bug to be public for posterity since there's no reason it should be private.) Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0587.html |