search

nutanix / terraform-provider-nutanix

Terraform Nutanix Provider
https://www.terraform.io/docs/providers/nutanix/
Mozilla Public License 2.0
95 stars 111 forks source link

nutanix AHV host affinity support #13

Open JonKohler opened 5 years ago

JonKohler commented 5 years ago

from https://github.com/nutanix/terraform-provider-nutanix/issues/185 @jttrail0

A large project was stalled today when we were unable to delegate host affinity today in relation to Prism Central/v3 API, we had not realized it was a feature that no longer existed. This was kind of an essential feature to spinning up and tearing down a big data cluster in which we do NOT want to migrate in the event of node failure.

It appears your client.go only uses the v3 as well as I did not see any v1 code support in the repo thus far. This was a feature in the past that appears to be pulled out of the v3 api, as the Prism Central web call looks to be done on either v0.8 or v1.

We would like not to have to work backwards to make this work as joining a cluster to Prism Central appears to remove the ability to add images to the cluster (they are now only added to PC) and I don't know that RBAC would migrate to Prism Elements alone.

Do you see a short term fix to managing host affinity... I was hoping Terraform would be the answer... our current RESTful stack is Ansible making a bunch of calls via the URI module and some templating magic (not ideal).

My original response:

Hey there @jttrail0 - thanks for reaching you. I know exactly what you're talking about. Funny, I just got another email internally about this same thing, like like it was forwarded on a few times from yourself. I've asked our team to add me to that mail as well.

You are right that our client.go is v3 only. I did this very intentionally, as the v3 API will be the way of the future, but you're spot on in that it has a few challenges:

The APIs are fragmented between v0.8, v1, v2, and v3. This is getting better with each release, but is still a reality. We've got a bit of work to do to truly get to a point where we can just fully deprecate all of the old APIs and just have ONE api per product. V3 API is not in an LTS branch yet, so all of this is STS code only. That all said, I'm curious - What exactly are you trying to do?

Asking as Terraform is an immutable infrastructure product, and Ansible by design is doing mutable changes to the instances that are provisioned.

Perhaps a cleaner way to do this is with ansible modules that talk to the various APIs, and could be plumbed into your playbooks properly, such that you're doing work from one tool only.

Also, WRT Images, that has changed back and forth over the past few releases.

Used to be that images were PE only. Then we swung to PC only (and the community slapped us hard on that). Now we've made it a bit of a hybrid, so it shouldn't be PC exclusive.

Either way, our vision for terraform is that it is almost ways going to be pointed at PC, so we're really trying to focus on making that multi-cluster management shine here, as we believe that most terraform high volume configurations will involve more than one cluster, so having everything in a single state file will nice.

trexmaster commented 4 years ago

I just hit this issue last week (had never user host affinity before) which led to Terraform crashing and the state being corrupted.

pmiles commented 2 years ago

Any progress on this ? Is been almost 3 years ...

Thanks