[LRP2] Hydra-ize local play and server deploys.

[JackUrb]

Overview

As LIGHT moves to having a single codebase that's supposed to deploy in many locations (devfairs, local development, production, etc), our previous method of passing opts around everywhere, doing initializations inline, and rewriting configuration parsing in multiple places is no longer flying. This PR consolidates around Hydra, pushing our configuration into StructuredConfigs and the hydra_configs directory.

Illustration
One big upside of this change is that configuration can either be compositional or written out to a single file. It also supports different schemas for different setups, such that:

# deploy/local.yaml
# @package _global_

defaults:
  - /light/model_pool: baseline
  - /schema/light/db: local
  - /light/db: local

hostname: localhost
port: 35494
safety_classifier_path: ""
is_logging: false
tutorial_builder: null

light:
  model_root: ~/LIGHT/models/

and

# deploy/prod.yaml
# @package _global_

defaults:
  - /light/model_pool: remote
  - /schema/light/db: aws-postgres
  - /light/db: prod

hostname: www.light-rpg.ai
port: 8080
safety_classifier_path: ""
is_logging: True
password: ""
disable_builder: true

light:
  model_root: /home/ubuntu/data/models/

can both be used to configure the same run_server.py launch script, even though the /light/model_pool: baseline default is set to load ParlAI models in-line, and /light/model_pool: remote is set to connect to a series of remote addresses (based on the contents of hydra_configs/light/model_pool/remote). Similarly, the arguments for local and aws-postgres database schemas are entirely different, but we can pull values from each properly.

Implementation

Big fixes

• ModelPool now implements a get_from_config_async method, which initializes a complete ModelPool from the ModelPoolConfig class (which dynamically has a field for every standard key in ModelTypeName).
• GraphBuilders and ModelLoader classes now set a CONFIG_CLASS which points to the correct structured config class that can be used to initialize them. hydra_registry.py can then use these to initialize the configs as schemas as well as a baseline default. Introduces a base_model_loader module to have better inheritance patterns.
• InteractionLoggers are no longer registered on creation of an OOGraph. These are instead created when the World is assigned an OOGraph, as the graph itself is just the representation of state, and the World has higher level configuration about a running game. These thus instead initialize on a World as well, and many callsites are changed to reflect this.

Following changes

• With hydra_registry.py set up, we now initialize it in the main import light call such that all confs are available.
• Some missing opts that used to be passed to OOGraphs have been added to the WorldConfig. Callsites are updated to include these where appropriate.
• ModelServer cleanup - now that we use hydra args, we can directly pass these along to the hydra pool to do the entirety of initialization.
• OOGraph no longer takes an opt, instead getting title and db_id as optional fields. Many callsites updated.
• Main Server opt deprecation:
  • GameInstance no longer takes in opt, instead wanting a GraphBuilderConfig to initialize the builder for it's games, and a WorldConfig to feed that builder when initializing worlds.
  • RegistryApplication no longer takes in opt or a LIGHTDatabase, instead getting a WorldServerConfig with everything it needs to initialize GameInstances.
  • run_server.py has been overhauled, now accepting hydra args and deferring model initialization to the ModelPool
• Server + Deploy config migration:
  • JS configs are stored in the server, python configs have all been centralized into hydra yamls.
  • build and deploy scripts now provide the hydra arguments and correct .js config files.
• Restructuring play_map.py to be hydra-safe
• Made some typing additions to keep sanity through all this

Discussions + Comments

1. While hydra_registry.py is required as a centralized place for all of actually registering configuration into the hydra system, the configs and subconfigs right now I've localized with what they configure (ie. MapJsonBuilderConfig is in the same file as MapJsonBuilder) for proximity/understanding. I've seen other structures of keeping these elsewhere to prevent dependency loops (configs and schemas in one place, implementations elsewhere), but I was wondering if that was really necessary here.
2. The whole TornadoPlayerProvider, GameInstance, RegistryApplication architecture of the main game server is something of a sprawling mess. This is due for a refactor into the WorldServer and LandingServer setup noted in the internal design doc, so please forgive the somewhat messy architecture here.
3. Wrapping run-scripts in @hydra.main as well as establishing the script configs feels a little boiler-plate-y but abstracting it into a @light_script(config=<>) may be hiding too much of it into magic. Unsure where I land here.

TODO

• Minimum functioning implementation
• Make setting password to "" disable login via password entirely.
• (in a follow-up PR) update the rest of the builders

Testing

• Automated tests are passing
• Local play_map.py, run_server.py, and model_server.py are working
• Dev and prod deploy are working.

[mojtaba-komeili]

I did not fully understand how the password was checked. I see that it is using Tornado's 3rd party Authentication. But don't know much about that. But overall looks ok to me.