Bug 1601347

Summary: User cannot change/select to different database in same namespace
Product: OpenShift Container Platform Reporter: Zhang Cheng <chezhang>
Component: Service BrokerAssignee: David Zager <dzager>
Status: CLOSED ERRATA QA Contact: Zhang Cheng <chezhang>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.10.0CC: aos-bugs, dzager, jiazha, zitang
Target Milestone: ---   
Target Release: 3.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-11 07:21:41 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:

Description Zhang Cheng 2018-07-16 07:29:48 UTC 
Description of problem: 
User cannot change/select to different database in same namespace. 
Please refer to trello card https://trello.com/c/5vybIGku


Version-Release number of selected component (if applicable):
asb: 1.2.17
apb: v3.10.18


How reproducible:
Always


Steps to Reproduce:
1. Provision mediawiki apb in project "test"
2. Provision postgresql apb(dev + 9.6 version) in project "test"
3. Provision postgresql apb(prod + 9.5 version) in project "test"
4. Create a servicebinding of postgresql apb(dev + 9.6 version) and add to mediawiki application
5. Try to access the route of mediawiki
6. Create a servicebinding of postgresql apb(prod + 9.5 version) and add to mediawiki application either
7. Check dc of mediawiki, there are two secretRefs at this point
8. Removed the secretRef of postgresql apb(dev + 9.6 version) from dc of mediawiki(and redeployed)
9. Deprovision the serviceinstance of postgresql(dev + 9.6 version)
10. Try to access the route of mediawiki


Actual results:  
4. (The first) servicebinding was created succeed and injected to dc of mediawiki
5. Access succeed.
6. (The second) servicebinding was created succeed and injected to dc of mediawiki either
7. Both secrets from servicebinding were added in dc of mediawiki.
    envFrom:
    - secretRef:
        name: aws-postgresql-apb-l95fp-credentials-j5nfj
    - secretRef:
        name: aws-postgresql-apb-q2lft-credentials-6nnqt
8. Redeployed succeed.
9. Deprovision succeed.
10. Cannot succeed (Lost Database)


Expected results: 
10. Access succeed, mediawiki is integrating with postgresql apb(prod + 9.5 version) database.


Addition info: 
None
Comment 1 David Zager 2018-07-23 14:45:21 UTC 
I am able to switch the database instance of a provisioned mediawiki using this method:

1. Provision mediawiki-apb in project "test"
2. Provision postgresql-apb (dev+9.6) in "test"
3. Provision postgresql-apb (prod+9.5) in "test"
4. Bind postgresql-apb (dev+9.6) to mediawiki
5. Access mediawiki

At this stage mediawiki is functioning and bound to the postgresql-apb instance (dev+9.6). In order to use a different DB, you must:

1. Remove the secretRef from the mediawiki deploymentconfig.
2. Save and wait for rollout to complete
3. Bind postgresql-apb (prod+9.5) to mediawiki
4. Access mediawiki

I have been able to consistently switch the backend database for mediawiki using this method (including postgresql, mariadb, mysql).
Comment 2 David Zager 2018-07-23 15:26:32 UTC 
Looking a little more closely, I see that all of the configuration information for mediawiki is being saved to the persistent storage. This means that my method was only working because I wasn't deprovisioning the other database APBs.

Working with Jason to see if there is an easy fix for this.
Comment 3 David Zager 2018-08-01 15:44:20 UTC 
mediawiki-container-scripts-1.3.1-1.el7.noarch has the fix for this issue. 

However, it is worth pointing out that this fix is specific to mediawiki and there is no guarantee that a user will be able to choose a random application + switch between different databases.

In the case of mediawiki-apb, it uses a PVC to save it's state in LocalSettings.php, in order for you to swap databases THIS FILE MUST BE REGENERATED. Modified steps would look like:

1. Provision mediawiki-apb in project "test"
2. Provision postgresql-apb (dev+9.6) in "test"
3. Provision mysql-apb (dev+5.6) in "test"
4. Create a binding for postgresql-apb (dev+9.6)
5. Add binding to mediawiki-apb application
6. Access mediawiki

We must first remove the binding secret from MediaWiki's deployment config so that the pod starts with no environment variables telling it where to find a database. When the MediaWiki entrypoint scripts see that there are not coordinates to a database, the LocalSettings.php file will be removed, this allows a subsequent binding to be made available in MediaWiki. Continuing the process from 6 above:

7. Select the mediawiki deployment config -> Environment
8. Remove the postgresql-apb binding secret from the "Environment From" section of the deployment config
9. Save this config and wait for the rollout to complete
10. Access mediawiki -- it should be as if no database was ever configured

Now we can bind to a new database of our choice:

11. Create a binding for mysql-apb (dev+5.6)
12. Add binding to mediawiki-apb application
13. Access mediawiki
Comment 4 Zhang Cheng 2018-08-03 06:58:01 UTC 
Verified and passed with mediawiki-container-scripts-1.3.1-1.el7.noarch

Test steps follow comment3
Comment 6 errata-xmlrpc 2018-10-11 07:21:41 UTC 
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.

https://access.redhat.com/errata/RHBA-2018:2652