RS RoomBot Application!

It sweeps, it mops. It swaps rooms for a few hundred guests at conference style events. Facilitates participants trading accomodations and answering the critical question of, "where the party at".

The RoomBot service allows guests to view which rooms they are assigned, and issue swap requests with other users. A lazy (time-boxed and out of band from this service) authentication process is used to validate room transfers. Some administrative functionality is available primarily in the form of reports.

Built With

• Django is good at managing relations and providing an api for controlling models. Used for the Room and Guest API model.
• React is good at consuming stuffs and making things look good while they flossing.

Quickstart

Additional details on these steps are available in this document.

• Contact an adult to request the contents of the "secret file". Put these contents into the .secret file in your local working copy.

Local Development

Docker should be available, and there are several system packages which must be installed (see Requirements section below).

# in one terminal - start the backend
$ make local_backend_dev
# in another terminal
$ make frontend_dev  # start the frontend
# in yet another terminal
$ make sample_data

At this point, the local environment will be live at http://localhost:3000/ and login with one of the sample credentials from exampleMainStaffList.csv. The example guest lists can now be uploaded at http://localhost:3000/admin/.

AWS Deployment

These instructions are for staging, however production is quite similar. Terraform is used to manage the infrastructure, and the roombaht_ctl is used to interact with the deployed host, including deploying build archives.

$ cd terraform
$ terraform plan
# review for unexpected changes. if this is start of the season, rds and staging
#   and assorted policies and dns should be marked for creation
$ terraform apply -auto-approve
# we only use the "ubuntu" user on first run
$ ./scripts/roombaht_ctl ubuntu staging provision
$ make archive
$ ./scripts/roombaht_ctl my_user staging deploy

The next set of commands will depend on which environment you are using. For this example, we will be loading sample data into staging.

$ ./scripts/roombaht_ctl my_user staging load_staff samples/exampleMainStaffList.csv
$ ./scripts/roombaht_ctl my_user staging load_rooms ballys samples/exampleBallysRoomList.csv
$ ./scripts/roombaht_ctl my_user staging load_rooms nugget samples/exampleNuggetRoomList.csv

At this point, the interface will be live, and admins may upload (sample) guest lists.

Environment / Configuration

Configuration is handled through environment variables, which are stored encrypted in GitHub. Secret management is handled through the ./scripts/secrets script. You must have a file named .secret in the top level of the Git repository. Contact an adult for the contents of this file. See below for full list of configurable settings.

• ./scripts/secrets decrypt <env> generate the <env>.env file from encrypted source
• ./scripts/secrets encrypt <env> encrypt the <env>.env file
• ./scripts/secrets show <env> display all the env vars in a format suitable for eval
• ./scripts/secrets show <env> VAR display the contents of the desired env var, stripped of quotes

Local Development

Requirements

• make (a classic)
• Docker configured in a way that networking and local file access works
• Minimum of Python 3.10 with virtualenv and uv
• A variety of "system packages" (note package names may vary on non-Linux)
  • build-essential
  • imagemagick
  • libpq-dev
  • python3-dev
• no not believin' in yo self

Frontend

This will compile the frontend and run a local server on port 3000.

$ make frontend_dev

This should build a docker image, use it to generate the react static, and then start react in dev mode listening on port 3000.

Backend

To configure and run the local development server, simply invoke the local_backend_dev target. This will ensure you have a properly configured virtualenv, load the default dev configuration, run migrations, and start the server. If it works, you will have an API server running on port 8000.

$ make local_backend_dev

You may (optionally) specify a different configuration file when testing locally. This can be done by setting ROOMBAHT_CONFIG to the full path of a configuration file.

$ ROOMBAHT_CONFIG=/path/to/my/special.env make local_backend_dev

As part of the startup, the full configuration will be shown, so you can confirm the right file was loaded.

Local Data Management

Local development also requires sample data. You may rapidly get up and running by leveraging our sample data. This will leverage a variety of the django management commands (see below). Sample data may be initially loaded via the sample_data make target. Local data may otherwise be interacted with via the djano management interface.

To get a guest password, you can use a Django management command. First, already have a running backend.

$ python backend/manage.py user_show name@noop.com
User Foo Bar, otp: SomeOtp, last login: never
    rooms: 305, tickets: aaa001, onboarding sent: yes

Infrastructure

AWS

The system is hosted in AWS and is managed via terraform. Please contact an adult for an AWS account and access to the EC2 ssh key. Any reasonably recent version of terraform will probably be fine. There are only three variables that should need changing. The ami_id cariable can be used to explicitly set a base AMI, and postgres_version is used to set the version installed in RDS. The staging and production variables can be set to true or false and control the existence of that environment. The RDS instance will be created if at least one of these is present, and removed if none of them are present.

Begin an infrastructure update by issuing a Terraform "plan". This will provide an indication of what is expected to change. Terraform should only issue changes to resources which have been modified in .tf files, along with any dependencies of those resources. Note that resources may change outside of Terraform - installed PostgreSQL version in RDS is one example. When these are encountered, update the version in meta.tf.

$ cd terraform
$ terraform plan

If there is nothing unexpected being reported, the apply command is used to make the changes. You will be asked to confirm, based on a new plan.

$ terraform apply

Initial / Baseline Host Configuration

Provisioning a deployed must occur before any other interactions. The provision functionality expects the existence of Ubuntu 20.04 server edition. This script is to be run when a host is first created and when any baseline non-application changes are desired. It will execute ./scripts/provision-remote.sh on the remote host. Note that the first time this command is run, the ubuntu user must be used, and the EC2 ssh private key must be available. All subsequent interactions with the deployed host must be through a normal user. SSH keys for users are pulled from GitHub.

$ `./scripts/roombaht_ctl ubuntu <env> provision

Managing a Real Host

There are a variety of scripts used for managing either the production (prod) or staging/dev (staging) environments. Please contact an adult for information on SSH access, hostnames, and the location of a perfect dry martini. May of these commands are accessed via the roombaht_ctl script, which provides a commmon execution interface.

$ ./scripts/roombaht_ctl <user> <env> <command> <arg1> <arg2> ....

Deployment

The deploy script will handle deployment to either the production (prod) or staging/dev (staging) environments. It handles the creation of artifacts, shipping and installing the artifacts, and configuring the remote host, database migrations, and other things needed for a running roombaht instance. The deployment script will ask for manual confirmation if you are deploying from a branch other than main or if the local git repository is dirty. You may bypass the confirmation by passing the -f option. But you shouldn't. You must locally build artifacts prior to deployment.

$ make archive
$ ./scripts/deploy <user> <env>

You may optionally execute a "quick" deployment. This skips the management of the virtualenv, database migrations, and the nginx configuration. Good for emergency fixes. Use with care. This may only be done after a "full" deployment has succesfully completed.

$ ./scripts/deploy <user> <env> -q
# shit's on fire yo and i just want to ship a code fix
$ ./scripts/deploy <user> <env> -q -f

Logs

There are shortcut commands which allow for easy viewing of backend (roombaht uwsgi / roombaht out-of-band) and frontend (nginx access and error) logs. These commands are accessed via roombaht_ctl.

$ ./scripts/roombaht_ctl <user> <env> backend-logs
$ ./scripts/roombaht_ctl <user> <env> frontend-logs

Data Management

Managing data on remote hosts is a whole thing. Please read this section carefully and make sure to leverage the DB Snapshot functionality (see below) for risky operations.

Data Population

These commands will populate the database with both sets of hotel files and the initial staff. Use caution when loading the same rooms over and over. Ask an adult before running this outside of staging.

./scripts/roombaht_ctl <user> <env> load_staff /path/to/staff.csv
./scripts/roombaht_ctl <user> <env> load_rooms ballys /path/to/ballys.csv
./scrip