"Why Are You Not Doing This With Ansible?"

A Single Question That Realigned Infrastructure Practice

"Why are you not doing this with ansible?"

These eight words, sent by a user at message index 2079 in a sprawling coding session about distributed S3 storage infrastructure, represent one of the most important moments in any engineering collaboration: the moment when process discipline reasserts itself over expedience. The message is short, direct, and devoid of technical detail — yet it carries enormous weight. It is not a question about what is being built, but about how it is being built. And in doing so, it exposes a fundamental tension between speed and consistency that every infrastructure engineer recognizes.

The Context: A Cascade of Manual Deployments

To understand why this question was asked, we must understand what preceded it. The assistant had been deep in the trenches of deploying a QA test cluster for a horizontally scalable S3-compatible storage system called FGW (Filecoin Gateway). The architecture involved three physical nodes: a head node running YugabyteDB, and two storage nodes (kuri1 and kuri2) running the Kuri storage daemon. The system had been working — after resolving "dirty migration" states in the CQL keyspaces and configuring the cluster topology — but there was a critical gap: cross-node S3 reads were failing.

When an object was written to kuri1, kuri2 could see its metadata in the shared S3 keyspace but could not retrieve the actual block data. The error message was telling: "block was not found locally (offline)." The Kuri nodes had no mechanism to fetch blocks from each other. The solution, as defined by the project's architecture, was to deploy an s3-proxy frontend — a stateless routing layer that would sit in front of both Kuri nodes, inspect the node_id stored in the S3 object metadata, and route each request to the correct backend.

What followed was a textbook example of ad-hoc infrastructure deployment. Over the course of messages 2073 through 2078, the assistant:

1. Copied the binary to the head node using scp and manually moved it into place with sudo mv
2. Created a configuration file by echoing a heredoc through SSH, only to discover the target directory didn't exist (the mv command failed silently)
3. Recreated the directory and re-ran the config creation
4. Wrote a systemd service file using sudo tee with another heredoc
5. Started the service — which immediately failed because the environment variable names in the config file didn't match what the binary expected The assistant then discovered, through grep, that the s3-proxy binary expected FGW_YCQL_HOSTS rather than RIBS_S3_CQL_HOSTS. The manual approach had introduced a naming mismatch that would have been caught by the existing Ansible templating system.

The Question Itself: What Makes It So Powerful?

The user's question is remarkable for what it does not contain. There is no criticism, no frustration, no technical correction. It is a pure, almost Socratic inquiry: "Why are you not doing this with ansible?" The question assumes that Ansible is the correct tool — an assumption grounded in the entire history of the project, which had invested heavily in Ansible roles for exactly this kind of deployment. The s3_frontend role already existed, complete with Jinja2 templates for configuration files, systemd service definitions, and proper variable management. The QA inventory file already had the host groups defined. Everything needed to deploy the s3-proxy through automation was already in place.

The question forces a reckoning with a specific kind of engineering failure: the failure to use existing abstractions. The assistant had fallen into a common trap — the belief that a "quick" manual deployment would be faster than updating the inventory and running a playbook. But the manual approach had already consumed multiple message turns and produced a broken service. The Ansible playbook, which had been tested and validated in previous sessions, would have produced a correct deployment in a single run.

The Assumptions at Play

The assistant made several assumptions that the user's question implicitly challenges:

First, the assumption of speed. The assistant assumed that typing SSH commands directly would be faster than editing YAML inventory files and running a playbook. This is a seductive assumption — the feedback loop of a single SSH command feels immediate, while Ansible requires editing files, running the playbook, and waiting for it to complete. But the manual approach's speed advantage evaporates the moment something goes wrong, as it did here.

Second, the assumption of disposability. The assistant seemed to treat the QA deployment as a one-off experiment where automation didn't matter. But QA environments are not disposable — they are the proving ground for production deployments. If the QA deployment doesn't use the same automation as production, it cannot validate that automation.

Third, the assumption of environmental knowledge. The assistant assumed that manually constructing environment variables would produce the correct configuration. But the binary's actual configuration keys (FGW_YCQL_HOSTS) differed from what the assistant wrote (RIBS_S3_CQL_HOSTS). The Ansible templates, having been built by someone familiar with the binary's actual configuration, would have used the correct names.

The Immediate Aftermath: A Pivot to Discipline

The assistant's response to the question is immediate and unambiguous:

"You're right - I should be using ansible properly instead of manually SSHing and creating ad-hoc configs. Let me fix this properly with ansible."

The assistant stops the manual service, reads the existing s3_frontend role, examines the Jinja2 templates, and updates the QA inventory to add the head node to the s3_frontend group. The playbook is run, and the s3-proxy is deployed correctly, with the right environment variable names, proper systemd integration, and the full audit trail that infrastructure-as-code provides.

Broader Implications: Infrastructure as Code as a Social Contract

The user's question is about more than just tooling. It is about the social contract of collaborative infrastructure work. When a team invests in Ansible roles, inventory files, and playbooks, they are investing in a shared understanding of how the system should be built. Bypassing that investment — even for a "quick" deployment — erodes the value of the automation. It creates configuration drift, where the manually-deployed service has slightly different settings than what the playbook would produce. It creates knowledge silos, where only the person who typed the SSH commands knows exactly what was done. And it creates risk, because the manual steps are not reviewed, not version-controlled, and not repeatable.

The question "Why are you not doing this with ansible?" is, in essence, a reminder that infrastructure is not a series of one-off actions but a continuously evolving system that must be managed with the same rigor as application code. It is a question that every infrastructure engineer should ask themselves, and each other, regularly.

Conclusion

The user's eight-word message at index 2079 is a masterclass in effective engineering communication. It is short, specific, and assumes good intent. It does not accuse or criticize — it asks. And in asking, it realigns the entire trajectory of the deployment, saving future debugging time, ensuring consistency with the rest of the infrastructure, and reinforcing the discipline of infrastructure-as-code. The question worked because the foundation was already laid: the Ansible roles existed, the inventory was structured, and the team had already committed to automation. All that was needed was someone to ask the obvious question at the right moment.