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 = TrueAnother 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.
The
sfa-adminCLI 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 thatsfa-admin list-userswill fail if there is not a Redis server running/available at127.0.0.1:6379since thelist-userscommand requires Redis butsfa-adminuses a defaultFlask()app that does not load everything thatsfa_api.create_app()loads (e.g.,REDIS_HOST,REDIS_PORT, etc.). Which means that when thelist-userscommand runs, it calls thesfa_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 as127.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, butsfa-admin list-userswill fail with an error about being unable to connect to Redis unless you have a Redis server running/available at127.0.0.1:6379without a password. This also happens if you connect to a k8s pod running thesfa-apiin production, since thesfa-apipod would have a Redis settings in its Flask app config but thesfa-admincommands don't reference the Flask app used by thesfa-apipod.One potential fix is to run
sfa-adminusing a Fake Redis connection. To make this easy, we could add a newConfiginsfa_api/config.pyspecific to thesfa-admincommands. For example:Another option would be to modify the
sfa-admincode to load the Redis settings in the same way as thecreate_app()function that's used for thesfa-apipods. 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.