The security_groups endpoint has various query parameters (globally_enabled_running, globally_enabled_staging, running_space_guids, staging_space_guids) that work individually, but cannot be used together to fetch ALL security groups that may be usable for a set of spaces.
Since these are filters, they simply execute AND queries, meaning that you cannot fetch all security groups that have space A as a running space or a staging space (or security groups that are global).
Since as far as I can tell we don't have any prior way of indicating API clients would like to execute an OR query, I think resolving this is a bit tricky.
Potential solutions:
- Implement a
space_guids param that executes an OR for running_space_guids and staging_space_guids. Could also check for global availability, though that might be counter-intuitive.
- Implement a way to specify OR queries. Would have to think deeply about this, as then we might be expected to implement that pattern for other endpoints.
- Change the current behavior. Probably a no-go as it would be a breaking change.
- Tell clients that they must use 4 queries to get all ASGs relevant to a space (not very good)
- something else
cc @geofffranks
The security_groups endpoint has various query parameters (
globally_enabled_running,globally_enabled_staging,running_space_guids,staging_space_guids) that work individually, but cannot be used together to fetch ALL security groups that may be usable for a set of spaces.Since these are filters, they simply execute AND queries, meaning that you cannot fetch all security groups that have space A as a running space or a staging space (or security groups that are global).
Since as far as I can tell we don't have any prior way of indicating API clients would like to execute an OR query, I think resolving this is a bit tricky.
Potential solutions:
space_guidsparam that executes an OR forrunning_space_guidsandstaging_space_guids. Could also check for global availability, though that might be counter-intuitive.cc @geofffranks