New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Nutanix external inventory script #21972

Open
wants to merge 1 commit into
base: devel
from

Conversation

Projects
None yet
10 participants
@mattkeeler

mattkeeler commented Feb 26, 2017

ISSUE TYPE
  • Feature Pull Request
COMPONENT NAME

Nutanix external inventory script

ANSIBLE VERSION
ansible 2.2.1.0
  config file =
  configured module search path = Default w/o overrides
SUMMARY

This is an inventory plugin for Nutanix, a 'hyper-converged' infrastructure platform. Multiple Nutanix clusters are supported. The script pulls from two APIs to generate an inventory of VMs, either by IP or VM name. Nutanix admins can specify inventory groups and hostvars by modifying the VM descriptions to contain a JSON string, the formatting of which can be found in the documentation at the top of the script.

ansible-playbook -i inventories/nutanix.py playbook.yml
@JonKohler

This comment has been minimized.

JonKohler commented Jan 24, 2018

Hey matt - I work in Nutanix engineering and would love to talk to you about this integration. Can you reach out to me - jon@nutanix.com? Would love to chat about possibly working together on this

@madeinoz67

This comment has been minimized.

madeinoz67 commented Jan 25, 2018

Would love to see integration, also working AWX/Tower

@JonKohler

This comment has been minimized.

JonKohler commented Jan 25, 2018

@madeinoz67 agreed. We actually have fully working modules that we use internally at Nutanix that we use for different things inside the company, we just never upstreamed them. @mattkeeler and I are connected on email now, we'll put our heads together and see if we can tag team them. My ultimate goal is to have a fully functional module upstream, where you can do typical CRUD workflows against Nutanix prism central, using our new v3 API's that are GA'ing shortly. This gets us a lot of goodness, and is the same approach that we're taking for terraform (as an example)

My gut feeling is that "MVP" would be CRUD for VMs, VLANs, Images, and Volume Groups. Once we've got that, we can take it upstream, and iterate based on feedback

@madeinoz67

This comment has been minimized.

madeinoz67 commented Jan 25, 2018

@JonKohler let me know if you need help testing/feedback, will be happy to help

yes have been looking forward to the new V3 API, look much cleaner

@madeinoz67

This comment has been minimized.

madeinoz67 commented Jan 25, 2018

@JonKohler while slightly off topic any change of an ansible nutanix module being released soon?

@JonKohler

This comment has been minimized.

JonKohler commented Jan 25, 2018

I'd venture to say its slightly on topic :) No hard date, but we're actively working on this. Once we've got something to test, we'll circle back here

@mattkeeler

This comment has been minimized.

mattkeeler commented Jan 25, 2018

Glad to see some interest in this from the community as well as from the good folks at Nutanix! As @JonKohler mentioned, we've connected over email and plan on seeing what we can come up with.

It's worth noting that the inventory plugin that has been submitted here is for a pre-v3 API. I haven't had the chance yet to play with v3, but doubtless it would benefit the community if the plugin supported it. I think a question that needs to be answered is whether the Ansible community would benefit from an inventory plugin that supports multiple API versions, or whether this needs to be updated to support v3 only.

Jon mentioned a module that Nutanix uses internally for controlling VMs, images, volumes, etc. My friend (primary author @abb1995) and I wrote a similar module that provides similar functionality, though it's also for a pre-v3 API and was never released. We've shared that with Jon as well, and are happy to work with him and his team if they find it useful. Right now it's in a private repo, but it might be worth opening to the community if there's interest.

So I guess the major question in terms of Ansible integrating Nutanix support is whether multiple API versions ought to be supported. Thoughts?

@JonKohler

This comment has been minimized.

JonKohler commented Jan 25, 2018

IMHO, with brutal honesty, I want to light the old v0.8 API on fire and never talk about it again :) Anything going forward should at least be v2 API, if not v3 API.

Thats an issue at large we've been working on within Nutanix to unify these disparate API's. v2 is what we call "procedural" and v3 is "intentful". Really its a traditional command API with v2 and a declarative API with v3.

Sure, the bar is a bit higher to rewrite/refactor, but I think its for the best if all of these toolsets walk the same code path

@madeinoz67

This comment has been minimized.

madeinoz67 commented Jan 25, 2018

yes I agree with @JonKohler I would feel that V2 would be a minimum as it currently stands, however if V3 release is not far off then aim for that as the base going forward. I'd be more than happy to help in any way

@ansibot ansibot added feature and removed feature_pull_request labels Mar 2, 2018

@brandonshough

This comment has been minimized.

brandonshough commented Jul 30, 2018

What's the latest on this @JonKohler ??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment