Summary:	ASTERISK-18441: TestSuite: AstDB: Test Plan Development
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2011-09-06 18:14:43	Date Closed:	2011-11-01 13:10:50
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Tests/testsuite
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	A test plan needs to be developed to exercise the the possible upgrade paths for the Asterisk database from 1.8 to 10.  This includes both the upgrades that can occur during a 'make install' and during a run-time upgrade.  Tests can include: 1. Manual tests (test descriptions on wiki) 2. Automated tests through the Asterisk TestSuite 3. Unit tests using the TEST_FRAMEWORK (if possible)
Comments:	By: Terry Wilson (twilson) 2011-09-07 14:15:20.701-0500 I can't think of a way to thoroughly test via the unit test an upgrade scenario. The upgrade automatically happens at Asterisk startup. By: Terry Wilson (twilson) 2011-09-07 14:16:13.422-0500 Setting original estimate to two days--assuming that the Testsuite already handles the ability to do an "upgrade scenario". By: Matt Jordan (mjordan) 2011-09-07 14:21:08.604-0500 Keep in mind this task is just to do the test plan, not actually write the tests.  The TestSuite does not handle anything pre- or mid-installation, so no, it can't check an upgrade scenario. As far as unit tests go, yeah, I didn't expect there'd be much we could do there. By: Terry Wilson (twilson) 2011-09-07 14:24:55.301-0500 Setting back to 1 day for coming up with different upgrade scenarios and figuring out what can actually be tested. By: Terry Wilson (twilson) 2011-10-10 13:13:02.011-0500 The astdb upgrade happens through calling the astdb2sqlite3 at runtime if the Berkeley DB astdb exists, but the SQLite3 astb does not. The astdb2sqlite3 utility is enabled by default in menuselect. Even if astdb2sqlite3 is deselected in menuselect, it is forced in during 'make' if $(ASTDBDIR)/astdb exists and $(ASTDBDIR)/astdb.sqlite3 does not. This makes the upgrade process almost, but not quite, foolproof. The upgrade process might fail if: # A user upgrades from Asterisk 1.8 to 10, configures Asterisk 10 to install in a different location than Asterisk 1.8, specifically disables the building of astdb2sqlite3, and moves the original astdb after building. In this case, astdb2sqlite3 will not be forced to build despite the user disabling it because there is no existing astdb file in the new location. When Asterisk 10 runs, it will attempt to convert the database, but the conversion utility will not exist. Asterisk 10 will then warn the user to manually enable the astdb2sqlite3 utility and re-run 'make' and 'make install'. # If a user runs Asterisk as a non-root user and has not granted the user permission to write to $(ASTDBDIR), SQLite3 will be unable to create the journal file in $(ASTDBDIR) and conversion (and future operation) will fail. Most tutorials show setting the /var/lib/asterisk directory to be writable by the asterisk user, but some (including the user who submitted ASTERISK-18174) might have just set the astdb file as writable. In this case, users will need to set 'astdbdir' in asterisk.conf to a directory where the asterisk user has write permission. The error returned in this case will be: {noformat} Unable to open Asterisk database '/var/lib/asterisk/astdb.sqlite3': unable to open database file *** Database conversion failed! *** Asterisk now uses SQLite3 for its internal *** database. Conversion from the old astdb *** failed. Most likely the astdb2sqlite3 utility *** was not selected for build. To convert the *** old astdb, please delete '/var/lib/asterisk/astdb.sqlite3' *** and re-run 'make menuselect' and select astdb2sqlite3 *** in the Utilities section, then 'make && make install'. {noformat} That the database could not be opened is the only error we get from the SQLite3 library. If we specifically wanted to test for this possiblity, we would have to try to create a temporary file in the directory and test for failure. Easier would be to just update the error message to include language that the astdbdir locaction in asterisk.conf must be writable by the user running Asterisk. # I am not sure how 3rd-party packaging (rpm/deb) is done. It is conceivable that they might bypass our normal menuselect procedures when building packages and might not include the astdb2sqlite3 utility at all. That would be bad. They should not do that. Testing these scenarios would almost certainly have to be done manually. I am not aware of a way to make the automated test framework re-install a new version of asterisk over an existing one, and unit tests certainly wouldn't be useful in that case. There are already unit tests to test that the SQLite3 db backend behaves identically to the Berkeley DB backend. I will add the above information to the Wiki page I am creating for the astdb migration. Of course, the basic test would just be: # Install and run 1.8 # Write to the astdb with CLI "database put" # Install and run 10 # Ensure that astdb.sqlite3 exists in the astdbdir One could verify that if astdb exists and astdb.sqlite3 doesn't, that astdb2sqlite3 always gets built even if disabled by menuselect. By: Leif Madsen (lmadsen) 2011-11-01 09:22:08.362-0500 Reassigned.