search

fly-apps / terraform-provider-fly

Terraform provider for the Fly.io API
BSD 3-Clause "New" or "Revised" License
114 stars 36 forks source link

Future of fly terraform provider? #255

Open kdevan opened 8 months ago

kdevan commented 8 months ago

Just to clarify, since #253 has been added which says, "This project is not currently maintained, and is not a recommended method of deployment to Fly.io.", I assume this means no one who works at fly is focusing on this provider? And if so, does that also mean PR's will not be accepted?

Is forking the recommended path forward for someone looking to update the provider as needed?

Is there another method recommended for automating fly infrastructure?

kdevan commented 8 months ago

Also, just thought I would ask, is there any chance a fix for volumes could go through and then the repo is unmaintained after that? I think that would allow many operations to continue with that one fix.

pi3ch commented 8 months ago

It seems nobody is looking at this. Today also creating machine using terraform start failing. Unsure if something change on Fly api side. Is there an active fork?

Create request failed: 401 Unauthorized, {"error":"malformed authorization header"}

gedw99 commented 8 months ago

wish we could get an official answer. I kind of liked using terraform for mass deployments.

mootari commented 8 months ago

@gedw99 You can find the official answer at the top of the Readme:

This project is not currently maintained, and is not a recommended method of deployment to Fly.io.

fermentfan commented 8 months ago

What the actual fuck guys. I chose Fly, because it allowed me to have my base setup in Terraform. Now I see a breaking change and need to see this happening as a paying customer. Instability of the platform I might accept for the moment, but deciding for such a regression in your functional offering really makes me question whether I still want to use Fly. I need to have access to my static IPs in my Terraform setup. I really dislike managing the certs without having it connected to my CloudFlare instance. And we also rely on machines being spawned, which is now broken.

And then there isn't even an official replacement. Advising to "use the CLI or API" is missing the complete point.

pi3ch commented 7 months ago

I am keeping a fork branch + terraform provider with things that I need. still works but It doesn't have all the fixes. PR welcome. https://github.com/pi3ch/terraform-provider-fly

otterDeveloper commented 7 months ago

What the actual fuck guys. I chose Fly, because it allowed me to have my base setup in Terraform. Now I see a breaking change and need to see this happening as a paying customer. Instability of the platform I might accept for the moment, but deciding for such a regression in your functional offering really makes me question whether I still want to use Fly. I need to have access to my static IPs in my Terraform setup. I really dislike managing the certs without having it connected to my CloudFlare instance. And we also rely on machines being spawned, which is now broken.

And then there isn't even an official replacement. Advising to "use the CLI or API" is missing the complete point.

I found out they existed looking through the Terraform Registry

mattfysh commented 7 months ago

I think I came to realize fly is more suited to hobbyists and prototypes, which is why all of the tooling is geared towards the CLI / manual work and no (longer) any devops/IaC type tooling

If you're using Terraform, Pulumi, or any other IaC framework, you're probably beyond the level of maturity offered by fly. I've recently started learning Kubernetes and am now migrating some of my services off of fly, particularly the ones that integrate heavily with the rest of my cloud stack. this has already solved a bunch of problems I was having with fly e.g manually managing secrets via the CLI was becoming cumbersome and error-prone.

I started with the EKS tutorials from Pulumi and realized k8s is nowhere near as scary as people make out. I had migrated an app over to EKS within a couple of days. If you're serious about managing all your infrastructure as code (especially their interdependencies, particularly secrets and connection strings) then I suggest fly might not be the choice for you

gedw99 commented 7 months ago

hey @mattfysh

I used k8 for a few years. It's great until it's not; like when things go wrong and you can work out what's the issue. It's a deep system. I think I saw a few people running k3 on fly.io btw.

https://github.com/superfly/flyctl/blob/master/api/go.mod has a fly API that the CLI embeds. Was wondering if anyone is using that to automate their git ops, CI, etc....