Bug 848472 - provider api create with bad type id defaults to vsphere
provider api create with bad type id defaults to vsphere
Status: CLOSED ERRATA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Unspecified
medium Severity low
: rc
: ---
Assigned To: Petr Blaho
Dave Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-15 12:54 EDT by Dave Johnson
Modified: 2012-12-04 10:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In the Cloud Engine API, the creation of a provider with a non-existent <provider_type/> resulted in a successful provider creation using vSphere as a default. This fix adds a check to see if the <provider_type/> is valid. The Cloud Engine API now returns an error if the <provider_type/> is invalid.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 10:16:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Johnson 2012-08-15 12:54:45 EDT
Description of problem:
=================================

Passed in a type_id of 100 which translates to a non existent record and the create call still succeeded and seemed to default to vsphere


-----Starting Test: errorWithBadType 
curl -X POST -d '<provider><name>errorTest-4sdf6</name><url>http://localhost:3002/api</url><provider_type id="100"/><deltacloud_provider></deltacloud_provider></provider>' -H "Content-Type: application/xml" -H "Accept: application/xml" --insecure -u admin:password https://hp-sl390s-01.rhts.eng.bos.redhat.com:443/conductor/api/providers
 
<provider href='https://hp-sl390s-01.rhts.eng.bos.redhat.com/conductor/api/providers/42' id='42'>
<name>errorTest-4sdf6</name>
<url>http://localhost:3002/api</url>
<provider_type>vsphere</provider_type>
<deltacloud_provider></deltacloud_provider>
</provider>


Version-Release number of selected component (if applicable):
aeolus-conductor-0.13.0-0.20120813220011gitd23ae4c.fc16.noarch
Comment 1 Petr Blaho 2012-09-04 05:08:26 EDT
There is missing check for nil value of one variable.

provider_type = ProviderType.find_by_id(provider_id)

return nil when there is no such ProviderType found.

The line where is used provider_type.id call is missing if provider_type check.

Without that check there will be nil.id call.

And there comes interesting part.

nil.id behavior is dependent on version of ruby and config options in rails.

for fedora 16 ruby 1.8.7-p358 and production environment

it returns 4
and notice "warning: Object#id will be deprecated; use Object#object_id"

for fedora 16 ruby 1.8.7-p358 and development environment

it raises "RuntimeError: Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id"

for fedora 17 ruby 1.9.3-p194 and production environment

it raises "NoMethodError: undefined method `id' for nil:NilClass"

for fedora 17 ruby 1.9.3-p194 and development environment

it raises "RuntimeError: Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id"


Patch will follow.
Comment 2 Petr Blaho 2012-09-04 05:09:44 EDT
Note: vsphere was always used because of that nil.id return value of 4 - id of this provider type.
Comment 3 Petr Blaho 2012-09-04 08:21:06 EDT
Continue:

In examples above production environment is how ruby behave.
Examples with development env is enhanced by this code - https://github.com/rails/rails/blob/3-0-stable/activesupport/lib/active_support/whiny_nil.rb#L40 .

This takes place only when config.whiny_nil = true in rails.
So this is the reason why different environments behave differently.
Comment 5 Steve Linabery 2012-09-07 17:57:54 EDT
in build aeolus-conductor-0.13.3-1.el6cf
Comment 7 Dave Johnson 2012-09-17 15:17:45 EDT
good 2 go in CFCE v1.1 2012-09-14.5 puddle

[root@hp-bl685cg6-01 ~]# curl -X POST -d '<provider><name>errorTest-4sdf6</name><url>http://localhost:3002/api</url><provider_type id="100"/><deltacloud_provider></deltacloud_provider></provider>' -H "Content-Type: application/xml" -H "Accept: application/xml" --insecure -u admin:password https://127.0.0.1:443/conductor/api/providers
<errors>
<error>
<message>Provider type does not exist</message>
</error>
</errors>
[root@hp-bl685cg6-01 ~]#
Comment 9 errata-xmlrpc 2012-12-04 10:16:15 EST
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-1516.html

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