More advanced filters for compute.getVMs, or at least by tags?

[zbjornson]

It doesn't look like there's a way to filter a compute.getVMs() call by VM tags. In fact, I can only figure out how to do simple string filters; none of the more advanced ones for the CLI seem to work.

Maybe these advanced filters should only be in the CLI because here we can use JS to filter however we want, and I don't know if the CLI filters client-side or server-side -- if it's client-side then this request is null. Having a filter option at all is tantalizing, though!

• gcloud-node version: 0.37

[stephenplusplus]

It seems like it must be client-side only. But, we could still add in some helpers for filters in our client, too. I think all get[Resource] methods take a filter string, so some way to make them easier to use could benefit our whole Compute API. Any interest in taking a crack at it? 😃

[zbjornson]

Hmm, if it's client-side (doesn't improve performance/reduce data traffic) then I'd lean toward leaving it up to the user because there are so many different kinds of filters that could be applied, it seems like it would be bloat and difficult to get right. That it would apply to all of Compute is a plus-side though...

What do you think of just enhancing the docs instead of state exactly what can be filtered (list properties) and how (provide examples)?

[stephenplusplus]

I think my idea got fuzzy in translation there, sorry. I'm thinking of a filter utility that just makes writing: filter: 'something = something && somethingElse = somethingElse' easier, like:

getSomethings({
  filter: {
    something: 'something',
    somethingElse: 'somethingElse'
  }
})

I'm not sure how useful or predictable to the user that would be, as I haven't written many filters myself. What do you think?

On your original point, I think we're in that special place where our client library tries to be smart and give the user what they probably want. As long as we explain what we're doing and have a way for the user to shut it off, it can only be a positive to give the user a fast path.

it seems like it would be bloat and difficult to get right.

Is it possible to just match what the CLI does?

[zbjornson]

Aha, yes -- something to translate from a convenient object to the cryptic filter string would be lovely! :)

Need to dig into this -- I haven't tested too much to see what exactly is possible with server-side filtering. Is the gcloud CLI open source somewhere? It would help to see how they are doing all of the more advanced filtering.

What would the object literal syntax be for "ne" (not equal) be? {name: {ne: "foo"}}, or "$not" maybe?

[stephenplusplus]

Is the gcloud CLI open source somewhere?

I don't know, actually. I don't think so, but @jgeewax -- is the gcloud SDK OSS?

What would the object literal syntax be for "ne" (not equal) be? {name: {ne: "foo"}}, or "$not" maybe?

That's a tricky one.

getSomethings({
  filter: {
    name: '!= myServer'
  }
})

I'm not sure about that idea, just throwing it out there. Is a filter builder going too far?

var filter = gce.filter()
filter('name').equal('my-server')
filter('name').notEqual('my-server')

// alternate version:
filter('name').is('my-server')
filter('name').not('my-server')

// alternate alternate version:
filter.set('name', 'my-server') // two args defaults to "is equal"
filter.set('name', '!=', 'my-server') // three args allows specific comparison

fetSomethings({
  filter: filter
})

More ideas welcome :D

[zbjornson]

Is a filter builder going too far?

Feels like java 😱 :) Either using magic strings ("ne" or "!=") seems fine, as does the MongoDB-like {field: {$not: value}} syntax, I think.

Playing around to try to figure out what is supported server-side. I think the GA API seems too limited for us to be able to help users out much, but the beta API has everything I'm looking for actually and would be where accepting an object literal would be useful:

Compute Engine Beta API Only: When filtering in the Beta API, you can also filter on nested fields. For example, you could filter on instances that have set the scheduling.automaticRestart field to true. Use filtering on nested fields to take advantage of labels to organize and search for results based on label values.

The Beta API also supports filtering on multiple expressions by providing each separate expression within parentheses. For example, (scheduling.automaticRestart eq true) (zone eq us-central1-f). Multiple expressions are treated as AND expressions, meaning that resources must match all expressions to pass the filters.

- https://cloud.google.com/compute/docs/reference/latest/instances/aggregatedList

Is there a policy on using beta APIs?

[stephenplusplus]

That is interesting... we should probably make it a single effort to upgrade all of our APIs to use the beta API, which would automatically bring the advanced filters with it. I'll make another issue to track upgrading to the beta.

So I guess for this issue to be resolved, we just need to decide if we want a simpler object to use for filters, or if strings are good enough. I'm cool with this if you are:

getSomethings({
  filter: {
    name: '!= myServer'
  }
})

@callmehiphop wdyt about this filter object idea?

[evaogbe]

This issue may no longer be relevant due to its age. Feel free to re-open.