Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1362301 - Changing session_store from cache to sql results in appliance losing database configuration
Summary: Changing session_store from cache to sql results in appliance losing database...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.6.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: GA
: 5.7.0
Assignee: Nick Carboni
QA Contact: Dave Johnson
URL:
Whiteboard: appliance:database
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-01 21:41 UTC by Lynn Dixon
Modified: 2017-12-05 15:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-16 19:33:31 UTC
Category: ---
Cloudforms Team: ---


Attachments (Terms of Use)

Description Lynn Dixon 2016-08-01 21:41:07 UTC
Description of problem:
In a newly deployed WebUI worker attached to an external database (VMDB machine), changing the session_store advanced option from "cache" to "sql" results in the appliance loosing its external database configuration.  This is to support session persistence when behind a load balancer with more than one WebUI worker

Version-Release number of selected component (if applicable):
5.6.0.13.20160624114606_13a9153

How reproducible:
Simply modifying the session_store parameter and waiting a few minutes.

Steps to Reproduce:
1. Deploy a new CFME appliance (same version as above).
2. Configure it to join region in an external database
3. Once joined to region, login to appliances webui and navigate to Configuration --> (server_name) --> advanced
4. search for session_store and chance the option from "cache" to "sql"
5. Save settings and wait a few minutes, or reboot / restart services on appliance

Actual results:
The appliance will lose its database configuration and the "summary section" shows the following:


Hostname:                cfme01web01.example.com
IP Address:              172.16.0.51
Netmask:                 255.255.255.0
Gateway:                 172.16.0.1
Primary DNS:             172.16.0.1
Secondary DNS:           
Search Order:            example.com
MAC Address:             00:1a:4a:16:01:6a
Timezone:                US/Eastern
Local Database:          not running
CFME Database:           postgres @ localhost
Database/Region:          / 0
External Auth:           not configured
CFME Version:            5.6.0.13
CFME Console:            https://172.16.0.51


Expected results:
Expect the session_store option to be successfully changed to sql and worker appliance functions normally as it has in previous versions.


Additional info:
This was done in my lab. After this happened the first time, I completely rebuilt the VM from scratch and was able to fully duplicate the problem following the steps above.  I took a snapshot before I made the change on the new VM.  I can provide logs and other information to help diagnose / troubleshoot if needed.  The failed appliance is still in a broken state right now if any logs are needed.

Comment 2 Lynn Dixon 2016-08-01 21:47:49 UTC
Going back and attempting to re-configure the database settings results in the following:

Activating the configuration using the following settings...
Host:     cfme01vmdb.example.com
Username: root
Database: vmdb_production

/opt/rh/cfme-gemset/gems/awesome_spawn-1.4.1/lib/awesome_spawn.rb:105:in `run!': /bin/systemctl exit code: 1 (AwesomeSpawn::CommandResultError)
        from /opt/rh/cfme-gemset/gems/linux_admin-0.16.0/lib/linux_admin/common.rb:24:in `run!'
        from /opt/rh/cfme-gemset/gems/linux_admin-0.16.0/lib/linux_admin/service/systemd_service.rb:21:in `start'
        from /var/www/miq/vmdb/gems/pending/appliance_console/database_configuration.rb:83:in `post_activation'
        from /var/www/miq/vmdb/gems/pending/appliance_console/database_configuration.rb:49:in `run_interactive'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:452:in `block in <module:ApplianceConsole>'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:106:in `loop'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:106:in `<module:ApplianceConsole>'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:90:in `<main>'
[root@cfme01web01 ~]#

Comment 3 Nick Carboni 2016-08-12 20:19:23 UTC
Tested this with build 5.6.1.2-20160810181333_8ba817b and couldn't reproduce the issue.

Can you retest with the latest build?

Also is it possible that you are hitting this[1] BZ which also has to do with worker failures around changing the session_store?

I wouldn't expect the database setting to be wiped out if it was that bug though.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1348632

Comment 6 Lynn Dixon 2016-08-16 19:29:04 UTC
Confirmed that this is resolved in version 5.6.0.13.20160624114606_13a9153

Tested latest build in my lab and was able to modify the session_store option to sql without any issues.

Comment 7 Nick Carboni 2016-08-16 19:33:31 UTC
Okay, if you're no longer seeing the issue, I'll close this as WORKSFORME.

Thanks for retesting Lynn.

Comment 8 Brant Evans 2016-08-18 22:13:08 UTC
(In reply to Lynn Dixon from comment #6)
> Confirmed that this is resolved in version 5.6.0.13.20160624114606_13a9153
> 
> Tested latest build in my lab and was able to modify the session_store
> option to sql without any issues.

I hope you meant version 5.6.1.2-20160810181333_8ba817b not 5.6.0.13...


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