Hide Forgot
Created attachment 1198341 [details] engine log Description of problem: When creating a NFS storage domain with invalid specific options - version, retransmission and timeout, the call from the API will ignore the invalid parameters and use the default once instead. For example: The API call: POST ovirt-engine/api/storagedomains <storage_domain> <name>NFS_SD_TEST</name> <storage> <address>NFS_SERVER_IP</address> <nfs_retrans>131077</nfs_retrans> <--- INVALID VALUE <nfs_timeo>761</nfs_timeo> <nfs_version>v3</nfs_version> <path>PATH_TO_NFS_SHARE</path> <type>nfs</type> </storage> <storage_format>v3</storage_format> <type>data</type> <host> <name>HOST_NAME</name> </host> </storage_domain> and the call in engine.log: 2016-09-06 19:00:13,967 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (default task-3) [393bc4a5] START, ConnectStorageServerVDSCommand(HostName = host_mixed_1, StorageServerConnectionManagementVDSParameters:{runAsync='true', hostId='5031c1d5-bdc7-441a-8f02-62c7212479ea', storagePoolId='00000000-0000-0000-0000-000000000000', storageType='NFS', connectionList='[StorageServerConnections:{id='829b6ece-c8c1-44ba-9219-26b854f1b308', connection='NFS_SERVER_IP:PATH_TO_NFS_SHARE', iqn='null', vfsType='null', mountOptions='null', nfsVersion='V3', nfsRetrans='5', nfsTimeo='761', iface='null', netIfaceName='null'}]'}), log id: 5ba5a140 The value of 'nfsRetrans' is 5 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Send a POST request to ovirt-engine/api/storagedomains with body: <storage_domain> <name>NFS_SD_TEST</name> <storage> <address>NFS_SERVER_IP</address> <nfs_retrans>131077</nfs_retrans> <--- INVALID VALUE <nfs_timeo>761</nfs_timeo> <nfs_version>v3</nfs_version> <path>PATH_TO_NFS_SHARE</path> <type>nfs</type> </storage> <storage_format>v3</storage_format> <type>data</type> <host> <name>HOST_NAME</name> </host> </storage_domain> 2. 3. Actual results: The storage domain will be created with default retransmission of 5 and no warning shown up Expected results: Additional info:
Does this fail as expected in V3?
Daniel, as this week's QA contact, can you take a look please?
Yes, It does fail in v3: Sending the same POST body in v3 and the response is: <fault> <reason>Invalid value</reason> <detail>Value 131077 is greater than maximum unsigned short 65535</detail> </fault>
@Juan - are we perhaps using a different IntegerParser in v3? (as it seems that the error is thrown from 'IntegerParser -> parseUnsignedShort')
In version 4 of the API all integers are 32 bit integers, there are no "short" integers. That means that we need to explicitly document and validate these values.
The proposed patch will change the API so that it explicitly validates these values, and returns the following error response in case of failure: <fault> <reason>Value out of range</reason> <detail>The value 131077 of attribute 'nfs_timeio' is outside of range 0 to 65535.</detail> </fault>
rhevm-4.0.5-0.1.el7ev.noarch: <fault> <detail> The value 131077 of attribute 'nfs_retrans' is outside of range 0 to 65535. </detail> <reason>Value out of range</reason> </fault>