499228 - Update SUMO staging database file (local.php)

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Paul Craciunoiu [:paulc]]

To enable metrics on stage (bug 398606) we will need the webroot/db/local.php file updated with the following variables (changed accordingly):
---
$metricsdb_host='localhost';
$metricsdb_user='data_warehouse_user';
$metricsdb_pass='data_warehouse_pass';
$metricsdb_dbs='data_warehouse_database';
---

The db user should have *read only* access and we should also have the data warehouse created (Cheng will file a bug on this, I believe)

Comment 1

[Dave Miller [:justdave]]

The database is question was created on bug 499347.

SELECT privs have been granted on the DB to the existing sumowiki user on mrapp-stage02.

Comment 2

[chizu]

Configuration on stage updated.

Comment 3

[E. Cooper [:ecooper]]

All of staging just died with a 'Unable to connect to the database !' error. See: https://support-stage.mozilla.org/kb/

Presumably, this update is to blame. local.php is a php file, so if the '---' lines from comment 0 were included, that'd cause an error. If they weren't, either the credentials changed or the db servers are down.

Comment 4

[chizu]

Credentials were wrong, justdave's fixed it.

Comment 5

[chizu]

Enabling this breaks logins on stage, see bug 500026. I've commented the metrics db config out for now, so reopening this.

Comment 6

[E. Cooper [:ecooper]]

If I were to guess, the error from bug 500026 is being thrown from webroot/db/tiki-db.php:148, which makes sense if getting rid of the settings resolves the problem.
http://viewvc.svn.mozilla.org/vc/projects/sumo/trunk/webroot/db/tiki-db.php?limit_changes=0&revision=28321&view=markup&pathrev=28321#l148

'An unexpected error [...]' errors are usually thrown due to failed db queries. Do the error logs have anything to say?

Comment 7

[chizu]

What types of queries (SELECT, etc...) does it run against the metricsdb database? We're only granting SELECT.

Comment 8

[Laura Thomson :laura]

Only need SELECT from the webapp.  Kettle needs write privs, but I think that has been covered elsewhere.

Comment 9

[Laura Thomson :laura]

chizu, I don't have access to stage (obviously) but maybe you could take a look at  /var/www/html/webroot/db/local.php and MySQL db setup on sumotools to compare?

Comment 10

[Laura Thomson :laura]

Also re https://bugzilla.mozilla.org/show_bug.cgi?id=500026, there should have been an error logged - was there anything in there?

Comment 11

[chizu]

No errors logged, apache logs show a completed request for the "an unexpected error has occurred" pages.

Looking at the sumotools config, the only difference is where the database is pointed and a lack of a slave database config on sumotools.

Comment 12

[Reed Loden [:reed]]

[Wed Jun 24 08:40:28 2009] [error] [client 10.2.81.4] PHP Fatal error:  Call to a member function check_script() on a non-object in /data/www/support-stage.mozilla.com/webroot/tiki-modules.php on line 11

Comment 13

[chizu]

Looks like the MySQL grants were just a bit off. Splitting out the users for each role (master, slave, metricsdb) and recreating the permissions solved this. Enabled on stage now.

Comment 14

[Paul Craciunoiu [:paulc]]

For some reason, the connection still isn't set up right, $metricsdb seems to point at the tiki database, not the warehouse:
http://support-stage.mozilla.org/tiki-metrics.php
(note the error)

Also, maybe this helps, I had the same problem as comment 12 on my local machine, but it worked fine on sumotools. My assumption is that I'm missing some packages on local that are present on sumotools.

Comment 15

[Reed Loden [:reed]]

(In reply to comment #14)
> For some reason, the connection still isn't set up right, $metricsdb seems to
> point at the tiki database, not the warehouse:
> http://support-stage.mozilla.org/tiki-metrics.php
> (note the error)

I can confirm that db/local.php has the proper configuration settings for the databases. Sounds like a code issue to me. Is there anything you wish me to try?

Comment 16

[Paul Craciunoiu [:paulc]]

I couldn't really figure this out locally either. Fairly sure it has to do with the adodb setup. As laura says in comment 9, we have a working setup on sumotools, perhaps look at the differences in set up, focus on mysql/php/adodb specific packages?

Comment 17

[Reed Loden [:reed]]

(In reply to comment #16)
> I couldn't really figure this out locally either. Fairly sure it has to do with
> the adodb setup. As laura says in comment 9, we have a working setup on
> sumotools, perhaps look at the differences in set up, focus on mysql/php/adodb
> specific packages?

I don't think it has anything to do with specific packages. The problem clearly looks like it's trying to use the wrong database for metrics stuff.

You aren't seeing this on sumotools because you have the metrics database in your sumo database, too. Try removing those four tables, and I'll bet you'll start seeing this problem.

Comment 18

[Reed Loden [:reed]]

Attachment: Probably this will help...

Comment 19

[E. Cooper [:ecooper]]

Comment on attachment 384920 [details] [diff] [review]
Probably this will help...

>-$metricslib = new MetricsLib($dbTiki);
>+$metricslib = new MetricsLib($metricsdb);

$metricslib = new MetricsLib($metricsdb, false);

The false param is needed. Otherwise, it will try to use the configured shadow db in webroot/lib/tikidblib.php unless the master is forced, which will cause issues. This *should* work. I'm still setting up metrics locally (and dealing with bug 500239), so I can't confirm.

Comment 20

[Laura Thomson :laura]

Comment on attachment 384920 [details] [diff] [review]
Probably this will help...

ecooper: commit it.