Bug 1375643

Summary: Validation not working for non-string values when assigning to smart variable via API
Product: Red Hat Satellite Reporter: Stanislav Tkachenko <stkachen>
Component: Smart VariablesAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WONTFIX QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2.0CC: jcallaha, orabin
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-02 20:59:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1411069    
Bug Blocks:    

Description Stanislav Tkachenko 2016-09-13 15:08:57 UTC
Description of problem:
When assigning 'default_value' or matcher 'value' that has different type than 'variable_type' and is not a string, null (for 'default_value') or actual value (for matcher 'value') is assigned instead of raising error.

For example,
1) Assigning default value using 'nailgun' syntax and HTTP response:
In this case error was not raised and default_value was set to null.

1.1) Create smart variable with integer variable type
> smart_variable = entities.SmartVariable(
>     default_value=50,
>     variable_type='integer'
> ).create()

1.2) Assign list of strings as default_value
> smart_variable.default_value = ['a', 'b']
> smart_variable.update(['default_value'])

1.3) Actual HTTP request and response (some parts are skipped)
> Making HTTP PUT request to https://example.com.com/api/v2/smart_variables/158 with ... 'headers':{'content-type': 'application/json'}} and data {"default_value": ["a", "b"]}.
> Received HTTP 200 response: {"description":null,"parameter_type":"integer","default_value":null,"validator_type":null,"validator_rule":null,"variable":"獮翤𨩔","id":158,"override_values":[]}

2) Assigning matcher value using 'nailgun' syntax and HTTP response
In this case error was not raised but matcher value was set to different type value.

2.1) Create smart variable
> smart_variable = entities.SmartVariable(
>     default_value=False,
>     variable_type='boolean'
> ).create()

2.2) Create matcher
> entities.OverrideValue(
>    match='domain=test.com',
>    value=50,
> ).create()

2.3) Actual HTTP request and response (some parts are skipped)
> Making HTTP POST request to https://example.com/api/v2/smart_variables/160/override_values with ... 'headers': {'content-type': 'application/json'}} and data {"smart_variable_id": 160, "value": 50, "match": "domain=test.com"}.
> Received HTTP 201 response: {... "id":37,"match":"domain=test.com","value":50,"use_puppet_default":false}

3) However, if assigned value is a string, validation works as expected:
> entities.SmartVariable(variable_type='boolean', ...).create()
> entities.OverrideValue(value="test", ...).create()
> Received HTTP 500 response: { "error": {"message":"Validation failed: Value is invalid boolean"}

4) Other type/value combinations that not caused errors:
variable_type='real', value=['a', 'b']
variable_type='array', value=True 

Version-Release number of selected component (if applicable):
Satellite 6.2.2 (build from 09/12/2016)


How reproducible:
Always

Steps to Reproduce:
1. Create Smart Variable via API, set default_value and variable_type to any valid values, e.g. 50 and 'integer'
2. Update Smart Variable with any new default_value that has different than 'variable_type' and is not a string, e.g. True
3. Read again that Smart Variable

Actual results:
Value is 'null' for 'default_value' or has a different type for matcher 'value'

Expected results:
1. HTTP 500 error with message "Validation failed: Value is invalid"
2. 'default_value' or matcher 'value' should not be updated.

Additional info:
Installed Packages:
* candlepin-0.9.54.7-1.el7.noarch
* candlepin-selinux-0.9.54.7-1.el7.noarch
* foreman-1.11.0.53-1.el7sat.noarch
* foreman-compute-1.11.0.53-1.el7sat.noarch
* foreman-debug-1.11.0.53-1.el7sat.noarch
* foreman-discovery-image-3.1.1-17.el7sat.noarch
* foreman-ec2-1.11.0.53-1.el7sat.noarch
* foreman-gce-1.11.0.53-1.el7sat.noarch
* foreman-installer-1.11.0.10-1.el7sat.noarch
* foreman-installer-katello-3.0.0.57-1.el7sat.noarch
* foreman-libvirt-1.11.0.53-1.el7sat.noarch
* foreman-openstack-1.11.0.53-1.el7sat.noarch
* foreman-ovirt-1.11.0.53-1.el7sat.noarch
* foreman-postgresql-1.11.0.53-1.el7sat.noarch
* foreman-proxy-1.11.0.6-1.el7sat.noarch
* foreman-rackspace-1.11.0.53-1.el7sat.noarch
* foreman-selinux-1.11.0.2-1.el7sat.noarch
* foreman-vmware-1.11.0.53-1.el7sat.noarch
* katello-3.0.0-12.el7sat.noarch
* katello-certs-tools-2.4.0-1.el7sat.noarch
* katello-client-bootstrap-1.1.0-2.el7sat.noarch
* katello-common-3.0.0-12.el7sat.noarch
* katello-debug-3.0.0-12.el7sat.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-base-3.0.0.57-1.el7sat.noarch
* katello-selinux-3.0.1.2-1.el7sat.noarch
* katello-server-ca-1.0-1.noarch
* katello-service-3.0.0-12.el7sat.noarch
* openldap-2.4.40-9.el7_2.x86_64
* pulp-client-1.0-1.noarch
* pulp-docker-plugins-2.0.1.1-1.el7sat.noarch
* pulp-katello-1.0.1-1.el7sat.noarch
* pulp-ostree-plugins-1.1.1-2.el7sat.noarch
* pulp-puppet-plugins-2.8.3.3-1.el7sat.noarch
* pulp-puppet-tools-2.8.3.3-1.el7sat.noarch
* pulp-rpm-plugins-2.8.3.5-1.el7sat.noarch
* pulp-selinux-2.8.3.4-1.el7sat.noarch
* pulp-server-2.8.3.4-1.el7sat.noarch
* python-ldap-2.4.15-2.el7.x86_64
* tfm-rubygem-ldap_fluff-0.4.3-1.el7sat.noarch
* tfm-rubygem-net-ldap-0.13.0-1.el7sat.noarch

Comment 2 Stanislav Tkachenko 2016-09-13 15:35:44 UTC
(In reply to Stanislav Tkachenko from comment #0)
Update:
Environment info:
>       OS: redhat
>  RELEASE: Red Hat Enterprise Linux Server release 7.2 (Maipo)
>  FOREMAN: 1.11.0.53
>     RUBY: ruby 2.0.0p598 (2014-11-13) [x86_64-linux]
>   PUPPET: 3.8.6
>  DENIALS: 0

Comment 4 orabin 2016-12-22 11:59:27 UTC
The api documentation states that default_value and the value field in override_value must be strings.
When a string is used the api works as expected.
Lowering the severity since the workflow according to the docs works and this doesn't prevent using the api.

I'm leaving this bug open because it should not replace the value but there should be an error message when anything other then string is sent or support for other types.

Comment 7 Bryan Kearney 2018-08-02 20:59:20 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the forseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.