feat (P4CR): Migrate configuration from shell scripts to Ansible playbooks

[gabebatista]

Use case

Summary

Replace the shell script-based configuration for P4 Code Review (Swarm) with Ansible playbooks to improve maintainability, idempotency, and consistency across the toolkit.

Solution/User Experience

The current configuration approach uses shell scripts (swarm_instance_init.sh, swarm_setup.sh) which present several challenges:

• Idempotency: Shell scripts require manual checks to avoid duplicate operations on re-runs
• Error handling: Complex conditional logic is difficult to maintain in bash
• Readability: Configuration intent is obscured by implementation details
• Testing: Shell scripts are harder to test and validate
• Consistency: Different modules use varying patterns and conventions

Ansible playbooks provide:

• Built-in idempotency for most operations
• Declarative syntax that clearly expresses desired state
• Mature ecosystem of modules for common tasks (package installation, file templating, service management)
• Native AWS modules for Secrets Manager, SSM Parameter Store, and other AWS services
• Easier testing with ansible-lint and molecule

Scope

Phase 1: P4 Code Review (This Issue)

• Convert swarm_instance_init.sh to Ansible playbook
• Convert swarm_setup.sh to Ansible roles
• Update Packer AMI build to use Ansible provisioner
• Update EC2 user-data to invoke Ansible instead of shell scripts

Phase 2: Future Expansion

• P4 Server configuration
• P4 Auth (HAS) configuration
• Unreal Horde configuration
• Jenkins build farm configuration

Proposed Structure

Alternative solutions

Alternatives Considered

Approach	Pros	Cons
Shell scripts (current)	Simple, no dependencies	Hard to maintain, not idempotent
Ansible	Idempotent, declarative, mature	Additional dependency
Cloud-init	Native to cloud instances	Limited functionality
Chef/Puppet	Powerful	Heavier weight, less common in game dev

Additional Context

• Ansible is already commonly used in game studio infrastructure
• Can run Ansible in "local" mode without requiring a control node
• Packer has native Ansible provisioner support
• Secrets will continue to be managed via AWS Secrets Manager (not Ansible Vault) since runtime retrieval and rotation are required