Add configuration building tool for orchestration on K8S

[jeehonglee]

Summary

Add configuration building tool for orchestration on K8S

Problem Definition

The features of testnet.go were not considered to allow the Tendermint blockchain to run on an orchestration engine such as K8S.
By allowing gaia to run on an Orchestration cluster such as K8S, anyone can easily create a gaia and participate. In addition, anyone could have many benefits from Orchestration tools such as K8S.

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

@jeehonglee thanks for opening up an issue. Note, the testnet command is a simple command that is solely meant to spin up a quick local network of a small number of nodes; it never had the intention to be involved in any kind of cloud infrastructure.

Now that being said, I'm of the opinion that having some sort of k8s or cloud-based automated infra would be amazing and much needed for Gaia. But I'd rather see this tooling as an extension preferably in a separate repo; either cosmos or community maintained. What are your thoughts on contributing a tool like this?

/cc @mircea-c @jackzampolin

[jeehonglee]

Thank you for quick replying @alexanderbez
I would like to share my thoughts about your response.

I understand your stance and the contents of the testnet.go file already.
If you ask me that why I want to add the feature to this repo, in my humble of opinions are two things.
Firstly, I would like to share some function and code with testnet.go and k8s.go.
e.g ) InitGenFiles, CollectGenFiles, WriteFile...
What I mean that testnet.go and k8s.go has the same configuration generating rule and it is necessary to fit to cosmos/tendermint configurations.
I think it is better testnet.go and k8s.go be updated together with changes and versions of cosmos/tendermint .
If we do not, It is easy to miss the change of the cosmos/tendermint. and we have to manage compatibility table between testnet.go <->cosmos SDK , k8s.go <-> cosmos SDK.

And I think there are no disadvantage and believe that it can lower the barriers of entry for those who participate in this project.
What do you think about it? :)

[alexanderbez]

@jeehonglee my only hesitation with including it alongside the testnet command is that we (the SDK team) will now be burdened with the responsibility of maintaining it which we don't really have the capacity to do. So I'd ask is this something that you can build as an open-source tool/command that leverages the public/exposed logic in testnet?

[mircea-c]

@jeehonglee adding to what @alexanderbez has already said, I would argue that, for a local development tool, adding a kubernetes layer would set the barrier of entry higher for no tangible benefit.

The major pain points in setting up a testnet would be the same (e.g. generating configuration files). The ancillary benefits like slightly easier logging tools integration are not use cases that this tool is meant for.

Having "testnets as a service" running on top of kubernetes might be a worthwhile use case, but it would have to be a separate tool / repo.

[happyprg]

Thank you for answering my IMHO. @alexanderbez , @mircea-c

So I'd ask is this something that you can build as an open-source tool/command that leverages the public/exposed logic in testnet?

What exactly do you mean? Do you want me to develop the functions and Make PR to here?
Actually, I already prepared the above codes and using it for provisioning multiple chains in the same bare-metal machines and I have plan to develop architecture.

@jeehonglee adding to what @alexanderbez has already said, I would argue that, for a local development tool, adding a kubernetes layer would set the barrier of entry higher for no tangible benefit.

I don't want to testnet.go includes the functionality of k8s.go.
I want to add it as a separate CMD module so that users can use choose the CMD separately according to their needs.
Therefore, we propose the hybrid version as below.

• In Same repo

1. for local net, nothing to change in usage) ... testnet --params..
2. for k8s, new CMD) go run main.go k8s build --params..

The only change to testnet.go is to refactor the duplicated code between 1) and 2) into another module or shared file.

[alexanderbez]

What exactly do you mean? Do you want me to develop the functions and Make PR to here?

What I mean is this a tool/feature you want to contribute and work on in a separate repo. Again, the issue here isn't the location within gaia, it's being in the repo at all. This is because of the maintenance overhead and k8s context that is needed. Neither of which we have.

Just to clarify, I'm all for this tool. I would just like to see it in a separate repo.

[jeehonglee]

@alexanderbez
Thank you for giving me your opinion. Got it.