Bug 1601347 - User cannot change/select to different database in same namespace
Summary: User cannot change/select to different database in same namespace
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.11.0
Assignee: David Zager
QA Contact: Zhang Cheng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-16 07:29 UTC by Zhang Cheng
Modified: 2018-10-11 07:22 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-10-11 07:21:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:2652 0 None None None 2018-10-11 07:22:03 UTC

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


Note You need to log in before you can comment on or make changes to this bug.