Solved

v3 - Filter syntax for /vms/list


Userlevel 1
Badge +6
Hello,

The /vms/list V3 endpoint takes filters as one of it's options, though it isn't explained how to use those filters in the documentation or in the REST API Explorer.
The documentation shows: filter - string - optional - The filter used for the results.

I've tried using something like "vm_name=foo" and various other combinations, but each time I get:

{"api_version"=>"3.0", "code"=>400, "kind"=>"vm", "message_list"=>[{"message"=>"Given argument is invalid. Could not process given filter criteria.", "reason"=>"INVALID_ARGUMENT"}], "state"=>"ERROR"}

Does anyone have an example of the filter syntax?

Cheers, Gavin
icon

Best answer by gsandie 31 October 2017, 12:36

I've figured out the syntax:vm_name==$thing_to_filter_on


View original

9 replies

Userlevel 1
Badge +6
I've figured out the syntax:vm_name==$thing_to_filter_on
Userlevel 7
Badge +35
Always cool when we are able to figure it out and share it back with the community - Thanks for sharing gsandie
Userlevel 1
Badge +6
You can also do "vm_name!=$thing_to_exclude" to filter on all vm_names apart from the ones you want to exclude.

Haven't figured out how to do a match on partials - e.g. "vm_name=~$thing_to_partial_match" - for those times you want to pull out a group of VMS with similar names.
Userlevel 7
Badge +30
yea, BTW, we ripped filtering support out of the v3 API GA at the last minute, because they didn't work the way we wanted them to.

We'll reintroduce it in a sane way in a future release, but just know for sure that will be a breaking change for you
Userlevel 7
Badge +30
(and BTW AOS 5.6 out today GA's the v3 APIs)
Unfortunately it seems to me that the Prism Central V3 API isn't quite fit for purpose yet. I don't seem able to do important things, like cloning VMs. Interestingly the Prism Central GUI ends up using a protected API gateway to do VM clones via the V1 API...
Userlevel 7
Badge +30
hey @John_B - thanks for the candid feedback. its certainly been a journey. I'm responsible for our external developer relations group here at Nutanix and I'd love to chat further - can you ping me jon@nutanix.com to chat a bit about what you're up to?

Would love to connect, please do reach out any time.
Badge +3
Substring matching seems to work with regexp:

"filter": "vm_name==.*test.*"

but it is case sensitive search and it is a bit clumsy to use [tT]est or similar to circumvent this.

@Jon , is there any update on filtering support in v3 API? At least the documentation seems to be very limited.
Userlevel 7
Badge +30
CristianS wrote:

Substring matching seems to work with regexp:

"filter": "vm_name==.*test.*"

but it is case sensitive search and it is a bit clumsy to use [tT]
est or similar to circumvent this.

@Jon , is there any update on filtering support in v3 API? At least the documentation seems to be very limited.


It's very limited since we haven't fixed the underlying mechanism in the way that we want to fix it.

In short, filter is all FIQL-based, but the key(s) (in the key-value pair you noted in your example) aren't the way we want to expose to the world. Meaning, IMHO, we shouldn't make people use all of the internal keys, and thats what we need to work on. its not intuitive. Exposing it this way would pose a backwards compatibility nightmare when we change it to the way we want to do it. The better answer (today) is to use paginated queries and client side filtering.

That said, if you absolutely, positively, want to do FIQL based filtering on the current version, hit me up on email and I'll spill the beans best I can ... jon@nutanix.com

Reply