Evergreen

Bug #2017941
Comment #8

Comment 8 for bug 2017941

Revision history for this message

Jason Stephenson (jstephenson) wrote on 2023-06-23 (last edit on 2023-06-23):

I had a look at the branches, and kicked the tires by running the Perl and PgTap tests. All tests passed, so that's good. I plan to exercise a few features in the coming days and possibly hook this up to a database with a production-sized data set.

I have a few suggestions based on the installation process:

1. The first time that I ran `osrf_control -l --reset-message-bus`, I got the following error: "Could not connect to Redis at private.localhost:6379: Connection refused." This was caused by not configuring Redis to listen on the public.localhost and private.localhost IPs configured in the hosts file. I recommend either adding an instruction to the OpenSRF README to add those IPs to the "bind" line in /etc/redis/redis.conf (my solution) or to change the instruction for /etc/hosts to use 127.0.0.1 for both the public.localhost and private.localhost domains.

2. More help on finding the passwords in the redis-accounts.txt file would be useful. I had to guess which lines they were on, and though it seemed kind of obvious, it may not be obvious to others.

3. Renaming 'redis-accounts.example.txt' to 'redis-accounts.txt.example' to be congruent with the naming of the other example files. (I tried using a for loop in bash to rename the examples, but this one slipped through.)

4. The opensrf_core.xml.example file still says "Jabber" and should be changed to "Redis."

5. A couple of junk files are left behind in the SYSCONFDIR. One is named "password" and the other looks like a password UUID. Both files are empty. They should be cleaned up by the process that sets the passwords.

I noticed 1 difference on the Evergreen side of things. When running 'make check' from ~/Evergreen/, make will attempt another compile of the code. This compile fails in the Redis branch, but succeeds in main. This is minor because 'make check' is supposed to be run from ~/Evergreen/Open-ILS/src/perlmods/, but it might be worth looking into why the compilation fails with 'make check' versus make.

This looks like a promising start. Thanks, Bill!

I had a look at the branches, and kicked the tires by running the Perl and PgTap tests.  All tests passed, so that's good. I plan to exercise a few features in the coming days and possibly hook this up to a database with a production-sized data set.

I have a few suggestions based on the installation process:

1. The first time that I ran `osrf_control -l --reset-message-bus`, I got the following error: "Could not connect to Redis at private.localhost:6379: Connection refused."  This was caused by not configuring Redis to listen on the public.localhost and private.localhost IPs configured in the hosts file.  I recommend either adding an instruction to the OpenSRF README to add those IPs to the "bind" line in /etc/redis/redis.conf (my solution) or to change the instruction for /etc/hosts to use 127.0.0.1 for both the public.localhost and private.localhost domains.

2. More help on finding the passwords in the redis-accounts.txt file would be useful.  I had to guess which lines they were on, and though it seemed kind of obvious, it may not be obvious to others.

3. Renaming 'redis-accounts.example.txt' to 'redis-accounts.txt.example' to be congruent with the naming of the other example files.  (I tried using a for loop in bash to rename the examples, but this one slipped through.)

4. The opensrf_core.xml.example file still says "Jabber" and should be changed to "Redis."

5. A couple of junk files are left behind in the SYSCONFDIR.  One is named "password" and the other looks like a password UUID.  Both files are empty.  They should be cleaned up by the process that sets the passwords.

I noticed 1 difference on the Evergreen side of things.  When running 'make check' from ~/Evergreen/, make will attempt another compile of the code.  This compile fails in the Redis branch, but succeeds in main.  This is minor because 'make check' is supposed to be run from ~/Evergreen/Open-ILS/src/perlmods/, but it might be worth looking into why the compilation fails with 'make check' versus make.

This looks like a promising start. Thanks, Bill!