Closed aegershman closed 4 years ago
@aegershman: I like what you're suggesting, but the terraform provider isn't there yet: it can't replace many of the Ansible tasks:
Maybe Terraform is the right solution to create the T0 & T1 routers, but there is a shortcoming with the T0 router creation — we can't seem to find a way to configure the uplink (a very necessary component of a T0 router), so our current plan is to let these pipelines configure everything up to the T1 routers, which we'll configure ourselves via Terraform.
Side note: the Terraform provider is focused on traditional SDN (software defined networking): firewall rules, IP address management (DHCP servers), subnets, routes, elastic IPs. In addition, it also enables configuration of NSX-T artifacts such as T0 & T1 routers.
[Edited]
@cunnie hi again. Thanks for helping set @aegershman he works along side myself on our platform engineering team. Could you shed some light on the use of these or other pipelines for additional configuration pieces after nsx-t is up? Such as NSX code upgrades as well as examples of tasks that could be used to configure anything that we would need to configure in NSX-T after its up. I ask because we want to make sure to treat all changes as code.
@xyloman Hi Bryan! Great hearing from you again. Sorry for the long delay in replying — I don't check my GitHub notifications as often as I'd like. Right now much of our Terraform configuration is in this repo: let me know if it works for you: https://github.com/pivotal-cf/terraforming-vsphere/tree/master/nsxt
In order to maintain infrastructure as code, could the creation & configuration of NSX-T components be deferred to the nsxt terraform provider rather than a tool like ansible? It feels like there's a lot of "magic" happening in in some of these tasks and I wonder if a better abstraction layer would be terraform.
This could make day-2 operations safer and more reliable. Terraform could be better suited for handling changes and upgrades.
Thoughts?