Ah, yeah it uses an S3 bucket to keep the Terraform state in. We need that particular state just for our team.
We should possibly refactor this though to use Digital Ocean ‘spaces’, meaning if there were any community users like yourself, you would need only a DO account, and not a DO and AWS account.
You could get it to work either by specifying your own S3 bucket (if you happen to have an AWS account), or you can delete this backend block, which will cause Terraform to just store its state locally.
If there were enough people interested in using the tool, I would say it might be a good idea to have a separate thread.
I am not going to continue wasting your time, so I’ll ask this one last question and then throw in the towel if I can’t make it happen. I am out of my depth with this tool.
Plan: 11 to add, 0 to change, 0 to destroy.
digitalocean_droplet.testnet_genesis: Creating...
╷
│ Error: Error creating droplet: POST https://api.digitalocean.com/v2/droplets: 422 30113222, 26204985, 29690435, 19315097, 26400596, 31216015, 29586082, 30878672, 30643220, 30643816, 26204781, 29201567 are invalid key identifiers for Droplet creation.
│
│ with digitalocean_droplet.testnet_genesis,
│ on genesis.tf line 1, in resource "digitalocean_droplet" "testnet_genesis":
│ 1: resource "digitalocean_droplet" "testnet_genesis" {
Honestly I don’t mind at all with trying to help, you can feel free to ask me questions any time.
So these somewhat cryptic numbers refer to IDs for people’s public SSH keys that have been added to the Maidsafe organisation in DO. It’s so that when the droplets spin up, each developer can have SSH access to the droplets.
If you feel like pursuing it further, you can get the ID from your own account, then just delete all these IDs and replace them with your own. I can’t remember off the top of my head how you get the number though.
If we wanted to make the tool a bit more generic, we would maybe need to read that ID list in from an environment variable or something like that.
If you do want to pursue it further, you can feel free to and ask me questions (although perhaps in a separate thread?), but if you don’t want to and feel like it’s sort of getting out of your depth, I totally understand that too.
Aye, I second @chriso here if it’s worthwhile pushing this we can look to PRs to make this more generic for folk to use more easily. It’s been a very internal tool thus far, but no reason it has to stay that way!
Not at all. As Josh says, people going through this is actually identifying how we can make the tool more generic and usable for others, so it’s useful for everyone.
@Josh So I just remembered that @StephenC wrote instructions on how to get those IDs.
So you need to add a public SSH key in your profile in DO. Then when you’ve done that:
Once added you need to use the D.O. api to get their ID, which you then add to the sn_testnet_tool:
* In terminal run: curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer <DO_PAT>" "https://api.digitalocean.com/v2/account/keys"
Note that the "Bearer" code is your DO_PAT (digital ocean personal access token)
* This lists all the users & their "ID" number. Got this cmd from https://developers.digitalocean.com/documentation/v2/#ssh-keys
So it seems like the droplets are created OK. However, after the droplets are created, Terraform runs a ‘provisioner’ to run scripts on the machines it’s just created. It does that over an SSH connection.
The output you posted above was possibly indicating that Terraform may not be able to connect to the machine to run the provisioner.
It’s worth checking that you can SSH to it from your own terminal, using your private key that’s associated with the public key you uploaded to DO.
