Question about Armory's custom Terraform Spinnaker Provider

[nicholasgcoles]

Thank you for building out this provider, it is awesome!

I was wondering, have you by any chance seen the terraform-provider-spinnaker, which was created by the guys at Armory?

Perhaps it is worth joining forces / projects so that there is no duplicate work going forward?
@ethanfrogers would be good to get your thoughts here!

[jgramoll]

I have not been in contact with anyone from the Armory repo. I've put a lot of effort into creating a definitive resources rather than just rely on json blobs which the other one uses

[jasonmcintosh]

The armory one was actually an experiment to see if there was enough interest to develop a product around such a provider. It works, uses the public API, and does pretty well for what it is. However, most of our customers use Dinghy - our corporate solution around GitOps style workflows OR some internal custom mechanism (aka the spin-cli tools & a job). @jgramoll has created is pretty impressive and is much more involved. A few thoughts on maybe some differences (not saying which is better) as they handle the problem with different methods.

1. This provider uses a custom client vs. the spinnaker maintained Go client. https://github.com/spinnaker/spin is the supported go client. An example impact: things like basic auth doesn't work in this provider where the armory one just uses the gate config file from spin. Other impacts would be long term changes in the API causing breaking changes in this provider. It's much more... "manual" to maintain & keep in sync.
2. One advantage on this one - you get POTENTIALLY code completion and other syntax "help". Aka you can use IntelliJ terraform stuff to auto complete syntax (though not tested that with a manually managed provider). There are fields for everything you need to fill out.
3. Though more "terraform" in nature with the different resources to control pipelines, triggers, etc. there is another caution flag similar to the challenges similar to the V1 vs. V2 provider. V2 fully allows manifests thus a large amount of flexibility and capability. I always worry about Terraform's very strict typing of resources. It's similar to the Terraform handling of k8s manifests and why many k8s users don't use the native kubernetes provider. For advanced users, it's quite possible the JSON version is more "useful". PARTICULARLY if your team isn't super terraform native, and just wants to do a "update the manifest and apply" kinda thing.