terraform-provider-cloudfoundry
terraform-provider-cloudfoundry copied to clipboard
cloudfoundry-community
Compatibility with CF v3 API resources
Firstly, thanks for maintaining this provider.
My question is regarding options for supporting v3 API operations for resources such as cloudfoundry_app etc and whether this is in the roadmap? This would then allow use of some more advanced CloudFoundry features available in the V3 API.
I can already see some resources make use of the V3 API client, but is there appetite to update other resources accordingly? If an approach has already been planned, i'd be happy to contribute.
Thanks for your input. We are running a bit low on contributors. Most of the changes are coming from @ArthurHlt , so I think the best is to wait for his input.
We welcome new features, as we see more and more people are using this provider, and we are happy to see if the community can benefit from your contributions.
we have client for v3 api already in our code and useable, but combine both is for now quite complicated to handle. For now just some features are selected and biggest change will be made when v3 api will be complete and cli using only v3 api (which is not still the case)
Thanks @ArthurHlt. I have started working on a V3 app resource in alphagov/terraform-provider-cf#1 It just about works for our needs (creating empty apps without manifests), but i'd appreciate your thoughts particularly regarding deployment structs. We would be happy to contribute further.
I'm more in big bang change for switching on v3 by switching all resources on v3 like the cli is actually doing it (with 2 different versions of the cli v6 and RC v7). And i would like also avoid to v3-resource as cli do on v6 like cf v3-push
that's would let you not have to set a v3 parameter on each resources.
However, deployment in v3 and allow multi buildpacks should be right now on this provider. In this case, in your fork for make things easier. I would make a structure joining v2 and v3 app structure as it must not change between them (this allow you to set memory, disk ... in addition). Remove v3 parameter in scheme, type of deployment (your v3standard) let you know what you should use as api version.
Take care that deploying an app in v3 is much more complicated than before, take a look at: https://docs.cloudfoundry.org/devguide/push-sub-commands.html (the beta hint is for the cli command not the process).
Thanks for starting the (big) work that's help
I asked the CAPI team about the V2 API deprecation, and it sounds like the 6-to-9 month window to transition to V3 will be starting soon. If there's an effort to migrate to V3 I hope to contribute some time to the most important resources for my team.
We have a pressing need for the V3 rolling deployments.
From initial work attempting to upgrade the dependent ccv2/ccv3 client libs, it looks like upgrading isn't going to be clean (and is too much work for our inital need) to do in a backwards compatible way without making the code a bit nasty, so we are going to have a stab at implementing V3 versions of the resources we need in our alphagov fork. Hopefully it will still provide a path to merge back in here (at the very least the code for deployments should be copy paste able back upstream if V3 migration work is performed here).
I'll post an update here once we have our cut down version of the provider operational.
First greenfield experiment implementing the set of app, droplet and deployment resources to provide v3 rolling strategy zero-downtime deployments:
- https://registry.terraform.io/providers/terraform-provider-cloudfoundry-v3/cloudfoundry-v3/latest/docs/resources/deployment
- https://github.com/alphagov/terraform-provider-cf#usage
(this is not going to be a long-lived fork! - just sketching out v3-friendly resources to give us zero-downtime-deployments)
