coverage: 78.713% (-0.03%) from 78.741%
when pulling 4b7747c on sapcc:fix-schedulerstats-listopts
into 5cb81d7 on gophercloud:master.

I think it makes sense to adjust the struct names as well so they correspond with the Pool struct.

Can you please clarify which renames you are thinking of?

As for the ListDetailOpts, does it make sense to omit it, since it has the same members as the ListOpts?

Done.

In addition I'd adjust unit tests to cover this change.

I don't have the time budget to build out tests for this right now. If it is required to have tests to merge a PR like this, then how was this struct added in the first place?

Can you please clarify which renames you are thinking of?

PoolName -> Pool, HostName -> Host, etc.

how was this struct added in the first place?

unit tests were initially with empty ListOpts.

I also wonder whether it's possible specify multiple capabilities

Since this is a bug fix, we have the flexibility to adjust the struct as needed and backport it to v2. Additionally, we could take this opportunity to update ListOpts to support multiple filters for the Capabilities (if supported) and change the type from string to []string.

Can you please clarify which renames you are thinking of?

PoolName -> Pool, HostName -> Host, etc.

Done.

how was this struct added in the first place?

unit tests were initially with empty ListOpts.

What would even be a useful test here? If a test is added that queries with ListDetailOpts{Pool: "foo"} and then checks against a fixture where ?pool=foo is observed, that's just entirely redundant with the specification of the struct in the type. If this test had existed for the previous implementation, then the fixture would probably have looked for ?pool_name=foo and just tested the wrong assumption anyway.

@majewsky I'm referring primarily to the Capabilities member to be a []string and if API allows to filter results according to multiple capabilities, we should implement this. For more context please see here. This case somehow stuck in my memory, which is why I’m emphasizing it.

This is clearly a bugfix. Thanks for submitting the PR. I think it makes sense to adjust the struct names as well so they correspond with the Pool struct. As for the ListDetailOpts, does it make sense to omit it, since it has the same members as the ListOpts? I also wonder whether it's possible specify multiple capabilities (like here).

Should we have been doing this here, as opposed to in a separate follow-up PR? By doing this, we've introduced major semver changes which we can't backport.

I'm going to pull those follow-up commits out of this PR and propose a new, follow-up one so that this can merge and be backported.

Scrub that: I don't have permission to do so with that fork. @majewsky would you be able to do this, and I'll happily review/approve?