[UI] Incorrect Error Handling for configs with priority 1

[Vadim Rovachev]

Precondition steps:
Sign in in horizon
open savanna tab
open "Cluster Templates" tap

step 1.
    click "Create Template"
    click "Create"

step 2.
    add Template Name

step 3.
    click parameters tab
        by Example: HDFS Parameters
    and erase default value of config with priority 1

step 4.
    click "Create"

expected result:
    correct error handling

actual result(by Example):
    Error: {u'HDFS': {u'io.file.buffer.size': None}, u'MapReduce': {}, u'general': {}} is not of type 'configs'

[Chad Roberts (croberts)]

I have confirmed that this bug still exists. I am unfamiliar with what a "priority 1" config is though. Does "priority 1" just mean that it is displayed by default?

[Sergey Lukjanov (slukjanov)]

@Chad, yup, configs with prio 1 are displayed by default.

[Chad Roberts (croberts)]

I'm still looking at this, but it's looking like the plugin is returning a set of config parameters correctly, but some values (at least io.file.buffer.size has its "required" attribute set to False, which is incorrect. I'm still poking around, but I think this might be an issue with the plugin.

[Alexander Ignatov (aignatov)]

This is not a plugin issue. I've reproduced and debug this issue following all steps in bug description.

So, when user erases some default value of some priority 1 field in the UI this value becomes "None" and is sent to the savanna as 'None'. And If you'll try, for example, to erase 'dfs.replication' field savanna will receive the following 'cluster_configs' field in the REST call body:
cluster_configs: {u'HDFS': {u'dfs.replication': None}, u'MapReduce': {}, u'general': {}}

Which leads to the validation error

2014-02-11 01:26:24.629 77319 DEBUG savanna.utils.api [-] Validation Error occurred: error_code=400, error_message={u'HDFS': {u'dfs.replication': None}, u'MapReduce': {}, u'general': {}} is not of type 'configs', error_name=VALIDATION_ERROR bad_request /Users/aignatov/work/savanna/savanna/utils/api.py:238

Validation check fails because savanna expects hadoop configs to be String, Integer or Boolean:
https://github.com/openstack/savanna/blob/master/savanna/utils/api_validator.py#L103-L106

And None value cannot be interpreted correctly.

So I think Savanna's behaviour in that situation is correct right now because we cann't pass None fields as hadoop parameters.
And solution would be to check None values on the UI side before sending creation request and substitute Nones with defaults.
Another solution is to send Nones to savanna and savanna itself will replace it with defaults

[Andrew Lazarev (alazarev)]

Savanna receives {u'io.file.buffer.size': None} and returns error about that. This behavior is fully correct.

The question is why UI sends {u'io.file.buffer.size': None}. I think the best solution is to remove configs with None value on UI side. But in this case it will be impossible to pass empty string as a value (which sometimes could be needed).

>So I think Savanna's behaviour in that situation is correct right now because we cann't pass None fields as hadoop parameters.
Agree

>And solution would be to check None values on the UI side before sending creation request and substitute Nones with defaults.
Don't agree. I think it is better to exclude Nones completely. It is up to savanna on that to do in that case.

>Another solution is to send Nones to savanna and savanna itself will replace it with defaults
Don't think it is good solution. Usually receiving None means that some error occurred on sending part. We can't just ignore it silently.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/73028

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/73028
Committed: https://git.openstack.org/cgit/openstack/savanna-dashboard/commit/?id=1e6e2a77ce2c0569bae79bea4536934969b07c89
Submitter: Jenkins
Branch: master

commit 1e6e2a77ce2c0569bae79bea4536934969b07c89
Author: Chad Roberts <email address hidden>
Date: Wed Feb 12 14:48:38 2014 -0500

    Treating blanked out config values as defaults for cluster templates

    If a dashboard user blanks out a value on the service config tabs
    of the cluster-template creation form, the dashboard treats those
    as their default values rather than an empty config (which causes
    errors).

    Fixes: bug #1212354

    Change-Id: If4b720045e78e1d65156c03f75a0cc93706d9015