Red Hat Bugzilla – Bug 1601347
User cannot change/select to different database in same namespace
Last modified: 2018-10-11 03:22:04 EDT
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
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).
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.
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
Verified and passed with mediawiki-container-scripts-1.3.1-1.el7.noarch Test steps follow comment3
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