search

vmware / terraform-provider-nsxt

Terraform VMware NSX-T provider
https://www.terraform.io/docs/providers/nsxt/
Other
129 stars 85 forks source link

Support for migration from manager API to policy API #854

Open martinrohrbach opened 1 year ago

martinrohrbach commented 1 year ago

Is your feature request related to a problem? Please describe.

My client has a large NSX-T environment that's gone through multiple updates and has been managed in large parts using the NSX-T terraform provider. As such, there are a lot of resources that have been built using manager API before the policy API even existed.

Manager API has been deprecated in NSX-T and now in the provider as well, however, there's no easy way to migrate between the resources other than duplicating everything using the policy API resources and deleting the manager API resources. This approach works fine (albeit being tedious) for things like firewall rules, however, it is not really an option for complex network topologies that you cannot simply duplicate and rearrange without major downtimes.

There is support from VMware within NSX-T to promote manager API objects to policy API "in bulk" and there are even procedures to do that for whole TKGI clusters. However, if the objects that are promoted have initially been created using Terraform then obviously they would have to be rewritten and imported again to be able to control them with Terraform after the promotion.

Describe the solution you'd like

I would like some kind of support for migration between manager API and policy API on the terraform side of things. This could be either

1) A way to automatically transfer existing manager API resource definitions (i.e. the terraform code itself) to the equivalent policy API resources. The switchover (create/delete/import/etc.) would still have to be handled by the user but the code migration would be sped up immensly.

2) An integration with NSX-T to both promote resources from manager API to policy API and at the same time transfer the terraform code as well as prepare the corresponding terraform remove/import statements to keep an existing state working after the promotion.

Describe alternatives you've considered

The alternative is, as described above, to individually rewrite every resource and create it in policy API before destroying the old resource in manager API.

Additional context

No response

github-actions[bot] commented 6 months ago

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

martinrohrbach commented 6 months ago

Since this nearly marks the first anniversary of this issue, may I ask if this is something that is to be considered?

annakhm commented 6 months ago

Hi @martinrohrbach, sorry this takes so long. We are considering it, however its a big task and other features were prioritized over it so far. Hopefully we can make it happen in the future, likely one step at a time (for example, first we provide a tool only to migrate config)