bitcoin-dev-project/warnet

Choose a cloud provider

Opened this issue · 4 comments

mplsgrant commented

I think we should use Digital Ocean as our cloud provider (edit) for TabConf. DO allows users to access the cluster with tokens in a way that does not require the installation of additional tooling like gcloud.

  • Do we have an account?
  • Who has access to the account?
josibake commented

I have been using Digital Ocean, but so far it appears the logging stack does not deploy. I also don't think we should prefer one cloud provider over another. Warnet should be able to deploy and run on whichever cloud provider or local setup the user prefers.

mplsgrant commented

Agree on being provider agnostic. I should have been more clear in my issue, because I want to dial in one provider for TabConf and get tested/running with that provider.

Regarding logging, I was able to run the install logging and connect logging scripts using my DO creds, and it appeared to work. I think @m3dwards mentioned that it failed at first but then started working after a couple tries.

josibake commented

I am hesitant to recommend we use provider X for Tabconf and instead make sure warnet works smoothly regardless of the backend. For one, I'm not sure who will be managing the cluster at Tabconf (Chaincode, one of us, the Tabconf organisers), so going off the assumption we can use whatever is available seems better.

It also helps keep us honest imo by making sure we don't over engineer for a specific cloud provider. Right now, our only restriction is "Cloud provider X needs to provide a way to authenticate via kubectl." Adding any additional restrictions on top off that (even just for Tabconf) seems like a bad idea to me.

m3dwards commented

I tend to agree with @mplsgrant here. I don't think he is recommending that we do anything custom to one cloud provider; we will continue to support all providers. That said, we have hit provider specific issues that are nothing to do with us or Warnet:

  1. Having to install google's tooling to access the cluster
  2. DO timing out installing prometheus

I think it's prudent this close out to just settle on where it will run and make sure that this is smooth.

Of the two problems, I prefer asking people to install the gcloud-auth-plugin