Repository navigation
Cinder Scheduler API #194
Description
Same as #179 it's be nice to get out an overall statistic for storage back-ends for admins to perform trend analysis and capacity planning.
Specific API to be targeted is http://developer.openstack.org/api-ref/block-storage/v2/index.html?expanded=list-back-end-storage-pools-detail
Will get the boilerplate written and tested while the discussion ensues.
Activity
jtopjian commentedon Nov 20, 2016
Given there's a timestamp in the response, it might make sense to wait until #190 is merged before working on this.
spjmurray commentedon Nov 21, 2016
Thanks for the heads up @jtopjian I'll ensure it meets expectation!
spjmurray commentedon Nov 25, 2016
Turns out worrying about timestamps isn't a big issue. After some digging it seems that the API documentation and reality are about as remote as the Andromeda galaxy. At a top level you have only got 2 fixed fields:
https://github.com/openstack/cinder/blob/master/cinder/api/views/scheduler_stats.py
Then it is up to the driver to respond with evidently what it likes (e.g. Pure storage vs Ceph RBD - it's all context specific. However the scheduler relies on a bunch of fields to work, which gives us common ground to go off and importantly extract the usage stats out of:
https://github.com/openstack/cinder/blob/master/doc/source/devref/drivers.rst#volume-stats
jtopjian commentedon May 21, 2017
I spent some time reviewing this. The API implementation is dizzying. Like @spjmurray mentioned, it's up to each volume driver to build the dataset to return. Some have a standard definition, but there's enough variance between all to cause concern.
In general, I think this is the best list to go off of. Scanning the various drivers, most implement this set. However, there are a handful that specify even more fields (example). I don't have access to these drivers to see if they're somehow filtered. I doubt they are.
So I think a good implementation would be to define a Result as the set of required and optional fields and then implement an extra field called something like
extra_fields, which would be amap[string]interface{}to catch the remaining. I think this last part could probably wait, both for ease of getting this in place as well as waiting on a decision/agreement of a standard way of implementing this as there are a few other PRs needing to do that.I think the work done in #205 can be amended with the remaining fields defined in the first link. @spjmurray Let me know if you want to continue with that, or I can take over.
@jrperritt Thoughts?
jrperritt commentedon May 21, 2017
I think that's fine. This came up recently in another PR, but the field was in the request body. The 'extras' field name should probably be the same as it was there (I can't remember exactly what it was).
spjmurray commentedon Jun 2, 2017
Been on holiday, looking at this now @jtopjian
jrperritt commentedon Jun 8, 2017
closed by #205
Merge pull request gophercloud#194 from jtopjian/readme-thankyou2