Add Ansible Playbook IaC option for agents

[avious00]

Similar to our deploy with terraform guide, create an ansible playbook and accompanying v3-docs guide that can be used by community operators

[avious00]

claimed by Polkachu ⚡️

[PolkachuIntern]

🫡

[TouchstoneTheDev]

claimed by Polkachu ⚡️

If claimed can you close this issue, or ya mean claimed means assigned ?

[avious00]

TouchstoneTheDev

assigned to! but i'm happy to create more devops bounties if you're interested and we have a bunch of other bounties up too

fyi all bounty payouts require a one-time KYC

[avious00]

Polkachu's work for this here: https://github.com/polkachu/hyperlane

[avious00]

@paulbalaji to review https://github.com/polkachu/hyperlane

[paulbalaji]

@PolkachuIntern this looks great, thanks for sharing! The only suggestion I have is to consider how to keep the agent configs up to date.

The main concern here is that the validators rely on the mailbox and merkle tree hook addresses, and although they haven't really changed - it's also not a guarantee that they will stay the same. I think it's also generally good practice to periodically sync with the latest monorepo state

I've mocked up a quick bash script here which can be used to do the above, it copies the chain-specific section from the mainnet_config.json

#!/bin/bash

HYPERLANE_MONOREPO_DIR="/path/to/hyperlane-monorepo"

# Loop through ${chain}.json files
for filepath in roles/hyperlane/files/*
do
    filename=$(basename -- "$filepath")
    extension="${filename##*.}"
    chain="${filename%.*}"

    if [[ $extension != "json" ]]
    then
        continue
    fi

    # Update only the specific .chains.$chain key in the chain configuration
    jq ".chains.$chain = input.chains.$chain" \
        "roles/hyperlane/files/$chain.json" \
        "$HYPERLANE_MONOREPO_DIR/rust/config/mainnet_config.json" > tmp.json \
        && mv tmp.json "roles/hyperlane/files/$chain.json"

    echo "Configuration for chain $chain has been updated successfully."
done

(Threw up a draft PR here)

You could either do this in the playbook itself to ensure the configs always match the latest versions in the repo you are building the validators from, alternatively I've left it here so you can periodically update the configs at your will. I'm thinking the latter option makes more sense, given that you will have your own public RPCs or config that you would want to use

[PolkachuIntern]

Thanks. I have merged the PR and responded to your comment. I am copy and paste the commend here too.

"thanks for the shell script. I will keep the script there, but I do not plan to use it for my own deployment. The reason is that we always prefer to use our own endpoints whenever possible and we often refuse any upstream dependency in order to avoid mistakes that we do not control ourselves. That's not to say you guys have mistakes. It is more about that if we find a mistake, the PR timeline is controlled by an entity outside of my control. That's just does not work with our preferred workflow.

The plan is that we will support only the hyperlane chains that we have our own deployments so the info will always be correct as long we our own deployment is running.

Finally, I want to add that we are not gunning for the bounty. This script is really designed to fit our own needs as we want to support many hyperlane chains. I can imagine that someone will fork this repo and maintain a version that integrate with your monorepo tightly. When that happens, that repo probably deserves the bounty more than us."

[avious00]

@bertux will attempt it this weekend, claimed by him

[bertux]

Finally, I want to add that we are not gunning for the bounty. This script is really designed to fit our own needs as we want to support many hyperlane chains. I can imagine that someone will fork this repo and maintain a version that integrate with your monorepo tightly. When that happens, that repo probably deserves the bounty more than us."

Thanks for the opportunity to integrate more tightly with the monorepo. I have forked the repository where the bash script has been merged and I will look to integrate in the Ansible part if it doesn't make it too heavy. A lighter approach would be to run it as a GitHub Action which would generate a Pull Request when there is some change. And I would like to support more chains there too because I am more into EVM chains so far. I will work on it at https://github.com/bertux/hyperlane-ansible

[bertux]

When it will work in my fork, I will prepare a PR here to integrate it into monorepo so it should make it easier to maintain.

[bertux]

I'm back, I will create the draft and I hope to finish.

[Maissacrement]

Project is down ? i'm interested too

[bertux]

Project is down ? i'm interested too

No, I was just too busy to finish it yet.

[Maissacrement]

Ok, i think i will wrote some proposal to you

[Maissacrement]

U can see my work here

[bertux]

@Maissacrement I've seen it, will you try to do a Pull Request on this repository to have the feedback from the maintainer of this personal repository ? We should try to get it adapted to this monorepo as it was done for Terraform. I'm working on a more innovative integration of Hyperlane, but I will try to test your work on this Ansible integration to give you feedback as well.

[Maissacrement]

@bertux Ok no worries I've been looking to test a multicloud approach and not aws only because i have too many error in config approch on premise. But it's so easy to copy what they did on terraform. But I prefer to stay on the approach of the group