Hide Forgot
Previously, there were no checks on inputs the user would enter on APBs. This often resulted in failed deployments. This fix adds basic validations for the inputs the UI recognizes and enforces. This avoids some of the more avoidable failures caused by bad input.
Description of problem: Currently mediawiki-apb and postgresql-apb don't have param validation. It is better to add param validation for them from UX in web. Such as add "pattern" for related params under alphaInstanceCreateParameterSchema Version-Release number of selected component (if applicable): oc v3.6.152.0 kubernetes v1.6.1+5115d708d7 How reproducible: Always Steps to Reproduce: 1.Create a project. Login to web console home page. 2.Select a APB serviceclasses(eg. mediawiki-apb). 3.In the pop-up window , fill in parameters with invalid values. Actual results: 3.Do not do parameters validation. Expected results: 3.Would do parameters validation. Additional info:
also: https://bugzilla.redhat.com/show_bug.cgi?id=1471730#c2
Aligning to 3.7.0
FYI, this time tried service postgresql-apb. When provisioning it, I didn't carefully think about common knowledge of a name for "PostgreSQL Database Name" and just typed 1111, after provisioning, the postgresql-1-f56j9 pod met Error: $ oc get pod NAME READY STATUS RESTARTS AGE postgresql-1-f56j9 0/1 Error 3 1m $ oc logs postgresql-1-f56j9 You must either specify the following environment variables: POSTGRESQL_USER (regex: '^[a-zA-Z_][a-zA-Z0-9_]*$') POSTGRESQL_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$') POSTGRESQL_DATABASE (regex: '^[a-zA-Z_][a-zA-Z0-9_]*$') Or the following environment variable: POSTGRESQL_ADMIN_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$') Or both ... snipped ... Now that it has underlying requirement about the params, changing bug title to "it should add ..."
Not in scope for 3.7.0, moving to 3.8.0
*** Bug 1500182 has been marked as a duplicate of this bug. ***
https://github.com/ansibleplaybookbundle/mediawiki-apb/pull/19 https://github.com/ansibleplaybookbundle/postgresql-apb/pull/28 https://github.com/ansibleplaybookbundle/mariadb-apb/pull/18 https://github.com/ansibleplaybookbundle/mysql-apb/pull/19
I fixed the pattern regexes for MediaWiki, Postgres, MariaDB, and MySQL. If there are better regexes or ones for other fields we should use, please let me know. MediaWiki regexes: Mediawiki DB Schema: "^[a-zA-Z_][a-zA-Z0-9_]*$" Mediawiki Site Name: "^[a-zA-Z]+$" Mediawiki Site Language: "^[a-z]{2,3}$" Postgres regexes: PostgreSQL Database Name: "^[a-zA-Z_][a-zA-Z0-9_]*$" PostgreSQL User: "^[a-zA-Z_][a-zA-Z0-9_]*$" PostgreSQL Password: "^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$" MariaDB regexes: MariaDB Database name: "^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$" MariaDB User: "^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$" MySQL regexes: service_name: "^[a-zA-Z0-9]+[a-zA-Z0-9-]*[a-zA-Z0-9]+$" mysql_database: "^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$" mysql_user: "^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$"
https://github.com/openshift/ansible-service-broker/pull/615 Added additional validations: - max_length - min_length - multiple_of - minimum - maximum - exclusive_minimum - exclusive_maximum Example parameters: - name: test_param_1 title: Test String type: string pattern: "^[a-z]*$" maxlength: 5 max_length: 6 min_length: 3 - name: test_param_2 title: Test Integer type: integer minimum: 0 maximum: 10 multiple_of: 2 - name: test_param_3 title: Test Number type: number exclusive_minimum: 1 exclusive_maximum: 4
https://github.com/openshift/ansible-service-broker/pull/615
Tested in env with reg-aws openshift3/ose-ansible-service-broker:v3.9.0-0.19.0, now all APB in comment 7 can validate corresponding parameters values and give prompt "String does not match pattern: ^...$" when value is invalid However, for the issue in comment 1 for bug 1471730 about Postgres APB, when User and Password are same, there is no validation and prompt to prevent it. Could you check again?
I did not try and address bug 1471730 in this fix. There is currently no way for the UI to validate one field against another, so validating the value of a password using a value for username is not currently possible. I believe that would be an enhancement outside the scope of this bug.
Xingxing, I think you can verify in here since I just opened another bug to trace the left things bug 1537955 . Thanks.
Thank you all, then let me move this bug to VERIFIED