sfa-admin list-users fails without Redis

[dplarson]

The sfa-admin CLI that gets installed/created with this package is needed to perform certain admin tasks by the hosts of the Arbiter platform. It works, but I did discover that sfa-admin list-users will fail if there is not a Redis server running/available at 127.0.0.1:6379 since the list-users command requires Redis but sfa-admin uses a default Flask() app that does not load everything that sfa_api.create_app() loads (e.g., REDIS_HOST, REDIS_PORT, etc.). Which means that when the list-users command runs, it calls the sfa_api.utils.queuing.make_redis_connect() and since Redis settings are not found in the Flask app's config, the Redis connection is attempted using default settings (which are currently set as 127.0.0.1:6379, as shown in sfa_api/utils/queuing.py#L6-L24).

The end result is that running other commands (e.g., sfa-admin list-organizations) will work fine, but sfa-admin list-users will fail with an error about being unable to connect to Redis unless you have a Redis server running/available at 127.0.0.1:6379 without a password. This also happens if you connect to a k8s pod running the sfa-api in production, since the sfa-api pod would have a Redis settings in its Flask app config but the sfa-admin commands don't reference the Flask app used by the sfa-api pod.

One potential fix is to run sfa-admin using a Fake Redis connection. To make this easy, we could add a new Config in sfa_api/config.py specific to the sfa-admin commands. For example:

class AdminConfig(Config):
    USE_FAKE_REDIS = True

Another option would be to modify the sfa-admin code to load the Redis settings in the same way as the create_app() function that's used for the sfa-api pods. But that seems more involved and doesn't seem to offer any clear benefit over using a Fake Redis connection for this relatively simple use of Redis.

[dplarson]

For more context: not being able to run sfa-admin list-users makes it inconvenient to get the UUIDs of users for tasks like adding users to an organization or promoting a user as admin for an organization. You can get info about a user from Auth0 given their Auth0 ID but need to either (a) use sfa-admin list-users to a user's UUID in the Arbiter or (b) connect to the MySQL database being used for the Arbiter and run SQL queries directly.

[dplarson]

Also, I'm opening this issue to help document this behavior since it's important but may not be something more than a few people are aware of (since it only impacts the sysadmin(s) of whoever hosts the Arbiter itself).