Drupal QA

Question: What can I do to help?
Answer: 1) You have a computer that can run Drupal.
* Install the testing client with this script: http://drupal.org/project/testing_server_setup
2) You have a server that can run Drupal and is accessible directly
over the Internet: e.g. http://example.com or http://example.com/testing-drupal
* Install the testing client with this script: http://drupal.org/project/testing_server_setup
* Create an account on the master server to get our client key. Your
client key is found by registering our client in your profile tab.
This is necessary for you client to be able to talk to the master.

Question: How can I set-up a testing client?
Answer: Install the latest PIFR 2.x client with this script http://drupal.org/project/testing_server_setup

Question: how can i contribute? I mean, I got no server which is accessible from the internet. So I wont be able to setup my own client. Without a client, is there anything i can do?

Answer: Right now we are testing version 2. I had three offers of servers today. But before I start matching the system
administrators to donated servers from the community I want to keep testing
as much as we can.

So in the near future, I'll be putting your public keys on many servers from
the community and you'll be able to start setting up these machines, and
doing performance. To get ready for this, you should get comfortable at
least installing the client on a server, even if we can not test it fully.

Question: Can I set-up a PIFR client in an existing Drupal environment running a production site?
Answer: Since the testing environment makes a number of changes to the existing web/php environment, I highly recommend that if you are attempting to setting up a PIFR client, you need to have it dedicated just to itself and no other Drupal instances.

An easy way would be to setup a primary web server instance for your normal Drupal sites then build/install Xen or VMware Server and use the virtual machines for your Drupal/PIFR testing environment.

Question: Client installed successfully, what's the next step?
Answer: Is your client reachable over the Internet? If it is, please log into the master server

In your profile, create a PIFR client key: /user/#####/pifr/add

Question: How do I run the command line script?
Answer: php /var/www/drupal/checkout/scripts/run-tests.sh --all

There are additional parameters to run-tests.sh that might make a difference:
--concurrency 1
--php /usr/bin/php
--url 'http://yourserver.com/checkout'
--verbose

Question: Are the enabled clients supposed to be processing tests? Mine says enabled, but it doesn't seem to be doing anything. It's shown a test count of X tests since it was enabled. Cron is running.
Answer: Project server is http://d6.drupal.org. I've added two patches: http://d6.drupal.org/node/367024, and http://d6.drupal.org/node/367026.

The server appears to configured correctly, as noted by the testing details here: http://d6.drupal.org/node/367024

Question: I have my test server up and running. See /pifr/test/X on the master server. I am wondering what is going to happen next, how are we going to start testing.
Answer: Once your client is connected to the master we need to see if patches are coming from the project server, http://d6.drupal.org to the
master and then to you slave, and then back to the master, and back to the project server. On the master, /pifr/status this indicates the number of patches queued.

Let us know if you see anything in your PIFR watchdog that indicates patches are getting tested on your site. We may need to manually run cron on the
master to trigger more patches being sent. But you can see if patches are queued up for testing on the master by looking at /pifr/status

Question: My client configuration tests failed. What should I do?
Answer: Check http://yoursite.com/checkout and make sure the URL is correct

Question: Can I run the tests if my server is not on the Internet?
Answer: Place pifr.php in the root of drupal to make test run without configuring master

Question: How can I log into your client's testing site so you can run simpletests manually and measure performance?
Answer: Hi, when you get a client site installed, but not necessarily
connected to the master, it will set up the "checkout" site which
includes the simpletest module. Your server does not have to be on
the Internet to do this.

You may want to run simpletest manually to do some performance
testing.

Here's what you need to do:
there is a password hash script in the scripts directory, /scripts or
http://cvs.drupal.org/viewvc.py/drupal/drupal/scripts/
create a password hash and change the uid 1 pass
php password-hash.sh --root /var/www/drupal/sites/default/files/
checkout/ "admin"
generates password for admin
Then follow "resetting your uid 1 password": http://drupal.org/node/68286
Now log into your site:
Username: admin
Password: admin
Go to admin >> development >> testing

Now you can manually run simpletest. Keep tuning your system to
speed up how long it takes to run all the simpletests.

Question: You get the error: Fetch test file: failed to retrieve file from project client.
Answer:

Question: Can you use a different port for the testing client?
Answer: I haven't tried using a different listening port for the client/server
interface. This might need to be looked into further to see if the
master can see http://mysite.com:portnumber/ correctly or not.

To give you an example of what I am doing, I host a number of websites
on my home network that are publically visible. To allow the master to
see my testing server, I am using Apache's mod_proxy to redirect the
incoming URL to your testing server (internal IP address) so it doesn't
impact any other websites you are currently hosting.

Attached is a PDF layout of what my home network looks like with Apache's 2.2.x mod_proxy for accessing the Drupal testing server. You might want to consider creating a similar environment. You can still use a virtual guest for the Drupal testing server instance/environment, but it needs to have the same IP subnet as the virtual hosting server -or- else you risk running into NAT and network IP addressing problems.

Another Answer: Thanx a lot, I have absolutely same configuration except apache computer is router with 2 network interfaces. And now I add
ProxyRequests Off in apache. Now I think that it works right because I try curl from internal host and it return right page.

But result is the same - Detect test run failure. [reason: Failed to
install Drupal on @environment.]

Question: 1: After running testing_server_install.sh, i was told that the user
name and password of the site is testingadmin and drupaltesting1. But,
I couldn't login and had to reset my password.

Question: 2: While logged in, I was not able to see the PIFR management page, i
could see only blank page. I found following error

require_once(sites/script.d6x.loc/modules/project_issue_file_review/
pifr.admin.inc) [function.require-
once]: failed to open stream: No such file or directory in /usr/
local/zend/apache2/htdocs/drupal/includes/menu.inc on line 346. I had to create a soft link to make this work.
Now everything is working fine.

Question: I am getting this error: Detect test run failure. [reason: Failed to install Drupal on @environment.]
Answer:

Question: Can I use an opcode cache?
Answer: - APC is not supported. I removed it and installed Xcache.
- Once xcache is installed, in /etc/php5/conf.d/xcache.ini, comment out the zend_extension line as shown here: http://drupalbin.com/10110
- eAccelarator is known to work as well.

Question: > Is there anything more I can do while installing to enhance performance and/or optimize performance. Or just a working installation will do?

Answer:Simpletest is in Drupal 7. So you try running all the core tests and
see how long that takes. Then start tuning your distro to make it go faster.

Ideally we are going to come up with a way to make sure our testing clients
are lightning fast. For example, we are currently down to a single testing
server for patches. It's taking:

06/26/2009 - 00:45Results sent to project server. 06/26/2009
- 00:42Result received from slave #17 (Passed: 11549 passes, 0 fails, 0 exceptions).
06/26/2009 - 00:09Test relayed to slave #17.
Which is too long.

Question: Is there a VM image?
Answer: There is, but it is not confirmed to work yet. http://ftp.osuosl.org/pub/osl/drupal/vm.rar

Question: What/where are the instructions to setting up a project server?
Answer: By project server, do you mean testing master?

The code for running the master is here:
http://drupal.org/project/project_issue_file_review

The code for running the project server is here:
http://drupal.org/project/project_issue_file_test

Installation instructions are here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project_...

The staging server we are using for the project server is d6.drupal.org

So we could configure the staging server to point to your project server. Or
you could set-up your own. It would pretty awesome to have more people
running the full suite for patches to their own site.

Question: is there a setting someplace in the PIFR Client to make a call/query to the master server - like every so many minutes?
Answer: ?

Question: Simpletest is part of D7 right? But, testing server install script checks out D6-12 core. Am i correct?
Answer: Correct. So from your webroot D7 is checkedout in /checkout The PIFR client is written as a Drupal 6 module, which is installed by the installations script.

Question: The only thing that didn't happen automatically for me was the download and installation of Drupal 7 HEAD into the checkout
directory. Is that meant to happen as part of running the testing_server_install.sh script or does another part look after that?

Answer: I believe that a checkout of HEAD occurs when a new patch is received from the master and the testing with the patch is triggered. So PIFR client does the checkout of HEAD and then runs the test. See: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project_...

You can run the simpletests from the command line using this scripts in the
Drupal 7 /scripts directory: http://cvs.drupal.org/viewvc.py/drupal/drupal/scripts/run-tests.sh?vi...
From the command line run: scripts/run_tests.php

Alternately log into Drupal 7, and go to admin >> developer >> simpletests

Question: How do I set-up a postgress client?
Answer: http://groups.drupal.org/node/23617#comment-81971

Question: how do I get the test server setup script to use Postgres rather than MySQL if both are installed on the same server?
Answer: Modified the profile to use Postgres 8.3 and saved it. Attempted the /var/local/testing_server_install.sh again. No go -- It creates the /etc/testing_server.conf, but within it is this:

$Id: testing_server.conf,v 1.1 2009/02/21 20:50:32 thehunmonkgroup Exp $
# Edit the values below before running the install script.

# Setup needs login information for a MySQL admin user that has
permissions to
# create databases.
MYSQL_USER=root
MYSQL_PASSWORD=
Nothing about Postgres at all.

Question: How do I confirm all the tests ran on my Drupal 7 test site?
Answer: drupal_checkout simpletest table should have ~11770 rows in it.
mysql> select count(*) from drupal_checkout.simpletest;
+----------+
| count(*) |
+----------+
| 12016 |
+----------+
1 row in set (0.00 sec)

Question: The next step that I was supposed to do was to go to the master server and register. I registered, but after that everything was dark, I'm not sure that I understand. Client? I put my server, then I got the key, which I don't what it is for.
what I did and then you'll tell me how to continue:
- I went to this the master server
- added the client (which I guess is my server)
- got the PIFR key (which I don't know what it is, except that it's used to check identity)
Where do I put it? If it's my server, exactly where (directory, file, database)? Please be more specific ("PIFR administration >> Client" where is that?), I have never done something like this before.

Answer: You get the key from the master, so the master knows are a legitimate client. Go to you PIFR administration >> Client to add the key from your master. Otherwise people could fake client results about patches. e.g. http://yoursite.com/admin/pirf/configuration

Question: I don't know what MySQL client type I have: MyISAM or INNODB?
Answer: To find our what your Drupal 7 engine type is, type the following from the MySQL command line:
> use Drupal_checkout;
> SHOW TABLE STATUS WHERE Name = 'user';
The engine type for your user table should be the engine type for all your tables unless you changed it. By default, it's MyISAM.

Question: Can I force my databases to be INNODB?
Answer: There are a couple of ways to force all new schema & tables to use InnoDB:
1) Use 'alter table
Engine=InnoDB;'
-- Note: I have a special script for this if anyone wants to use
it for converting existing database schemas to InnoDB.
2) Modify /etc/my.cnf and after [mysqld] add the following line:
default-storage-engine=innodb
Just remember to uncomment out the innodb portion of the my.cnf as well to allow InnoDB to engage. Then restart the mysql server so everything takes effect.

Question: How powerful does my server have to be to contribute to the testing pool?
Answer: Your server has to be able to test a patch within 45 minutes with the default timeouts. You server can be optimized using a database on a RAM disk with opcode caches to achieve faster testing.

Question: Are there Virtual Machine images we can use?
Answer: We need to think little more. Image have hardcoded IP address and suppose some other parameters to change before it starts to be usable. For example /etc/apache2/vhosts.conf server IP and name. Suppose most efficient way to make better script to setup server. I have some ideas but too busy now.
All we need is
1) Check environment (versions of soft to be used)
2) create 2 database with username and password
3) cvs checkout current drupal-6 and pifr 2
4) make apache|lighthttp|nginix config for virtual host
5) setup drupal6 and enable pifr module, then make setup of client
Still think that we can limit distros by using profiles (already done) but we need better check for env

Question: I have a server, can I give you a username and password to the server?
Answer: No, we prefer to have accounts for each user and to access the server with public_keys which is a more robust form of authentication than usernames and passwords.

Question: Testing.drupal.org seems to be running, why are we adding more servers?
Answer: 1) Testing.drupal.org has been running for several months using the 2nd generation Project Issue File Revew (PIFR 1.x) of automated
testing. For a variety of reasons, the testing slaves are failing regularly. This is impacting Drupal core development negatively.

Question: I am learning how to set-up PIFR testing server. Should I start with PIFR 1, PIFR 2?
Answer: 2) We need system administrators who can help administer and debug PIFR 1.x servers. It is easier to install the third generation or PIFR
2.x clients so we are asking you to start with 2.x. Once you learn how to get the easy version installed, we will ask some of you to help
debug the crashing 1.x servers. Most of the run-time code is the same between 1.x and 2.x. The big differences are that 2.x is easier
to set-up and it has more self diagnostics, and the ability to fail gracefully and not screw up the Drupal.org issue queues.

Question: I want to talk to someone in realtime about running a PIFR server. Where can I go to talk to someone?
Answer: #drupal-infrastructure on irc.freenode.net with an IRC client

Question: I am a system administrator, but I don't have a server. Can I help?
Answer: Yes, We have servers for you, and we will install your public keys on them so you can help debug. Right now we are limited by system
administrators who can monitor errors, and respond to those errors.

Question: I don't have a lot of time, can I still help?
Answer: If you don't have a lot of time, but still want to help, you run the tests manually in a Drupal 7 checkout of head. The tests can be
run manually through the UI. Admin >> development >> Simpletests. If you want to measure performance of the tests, use the command line
script at scripts/run_tests.php. If you've successfully set-up the PIFR 2.x installation client, a Drupal 6 site, then the Drupal 7 site
is at /checkout and is symlinked to your /files directory.

The more system administrators who we can train, the more bugs we can find, and then the developers can focus on what they do best, writing
patches to make the testing.drupal.org software more robust.

Question: I have a solution to problem I found with the testing client. How can fix the PIFR client?
Answer: You can file an issue with a patch at http://drupal.org/project/issues/project_issue_file_review

Question: I got my client up, registered and got a key. Filled in my info on my machine. Started testing this morning and it says it is still testing.
Is it suppose to be taking this long? If not should I reboot my machine.
Answer: No, it's not supposed to take that long. You could reboot, but you should also go to Administer - PIFR Management and click Toggle reset
and run cron again.

Question: Is there a way to make the tests run faster on my server?
Answer: Yes. By moving the database to a RAM Disk we were able to get tests to go from 50 minutes to 3 minutes. See http://drupal.org/files/mysql-tmpfs.txt, attached to http://drupal.org/node/466972. Also see http://testing.drupal.org/performance-tuning-tips-for-D7

Question: I configured PIFR2 and got this error in my watchdog "Failed to request next test: Server error. Requested method pifr.next not specified."
Answer: The server URL for the master is incorrect, please confirm you have the right URL.

Question: I configured PIFR2 and enabled testing and got this error in my watchdog "When requesting next test, server responded: Invalid server (client key may have been disabled)"
Answer: Your client failed a configuration test. Add pifr_client.php to your webroot directory and browse to http://yoursite.com/pifr_client.php. Let the tests run and see if all the tests pass.

Question: I found an error in my webserver logs:
[Tue Jul 14 10:41:23 2009] [error] [client 85.234.149.143] Invalid URI in request GET HTTP/1.1
patch: **** Only garbage was found in the patch input.
Answer: This patch is added intentionally to make sure bad patches are handled.

Converting from MySQL client to sqlite

• Update settings.php with the new DB: $db_url['pifr_checkout'] = 'sqlite://localhost/var/www/checkout/.ht.drupal_checkout';
• On the client at admin/pifr/configuration, change to sqlite
• On master at admin/pifr/server, edit the specific client you're converting to change it's expected environment