Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose a cloud provider #505

Open
2 tasks
mplsgrant opened this issue Sep 2, 2024 · 4 comments
Open
2 tasks

Choose a cloud provider #505

mplsgrant opened this issue Sep 2, 2024 · 4 comments
Milestone

Comments

@mplsgrant
Copy link
Collaborator

mplsgrant commented Sep 2, 2024

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?
@mplsgrant mplsgrant added this to the Tabconf milestone Sep 2, 2024
@josibake
Copy link
Collaborator

josibake commented Sep 2, 2024

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
Copy link
Collaborator Author

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
Copy link
Collaborator

josibake commented Sep 2, 2024

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
Copy link
Collaborator

m3dwards commented Sep 3, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants