Repository navigation
Conversation
|
@spjmurray Nice! I'd love to see this added. Can you open a corresponding Issue per the style guide? This helps separate feature discussion vs code review discussion. For the code itself, one question I have is whether or not this should go under directly under the |
|
Sure thing @jtopjian. Reads Also FYI the end goal of this is related to influxdata/telegraf#243 |
|
@spjmurray This just might make me revisit InfluxDB now... |
|
@jtopjian Here's some more fun InfluxDB related things I've done to really stoke a fire ;p http://www.datacentred.co.uk/blog/icinga-2-5-released/ http://www.datacentred.co.uk/blog/ceph-monitoring-telegraf-grafana/ |
10f6a0a to
e4c6181
Compare
|
@spjmurray is this still correctly labeled WIP or is it ready for review? |
Adds in support to list all available hypervisors (detailed) for applications such as monitoring and capacity planning. For gophercloud#179
e4c6181 to
530d34d
Compare
|
Apologies @jtopjian this got buried in my inbox and forgotten about. Yes this is ready for review, I've stripped the WIP out of the pull request and the commit message. |
jrperritt
left a comment
There was a problem hiding this comment.
I've made some comments (mostly stylistic). If you'd prefer, I can submit this code as a PR, which makes most of the changes I mentioned on top of your commit.
The style guide should mention all the changes needed.
| Arch string `json:"arch"` | ||
| Model string `json:"model"` | ||
| Features []string `json:"features"` | ||
| Topology `json:"topology"` |
There was a problem hiding this comment.
Let's name this field (Topology).
|
|
||
| type Hypervisor struct { | ||
| // A structure that contains cpu information like arch, model, vendor, features and topology | ||
| CpuInfo `json:"cpu_info"` |
There was a problem hiding this comment.
Let's change this to:
CPUInfo CPUInfo `json:"-"`| // The number of running vms on this hypervisor | ||
| RunningVMs int `json:"running_vms"` | ||
| // The hypervisor service object | ||
| Service `json:"service"` |
There was a problem hiding this comment.
Let's name this field (Service).
| // The hypervisor type | ||
| HypervisorType string `json:"hypervisor_type"` | ||
| // The hypervisor version | ||
| HypervisorVersion int `json:"hypervisor_version"` |
There was a problem hiding this comment.
Let's change this to:
HypervisorVersion int `json:"-"`| // Newer versions pass the CPU into around as the correct types, this just needs | ||
| // converting and copying into place. Older versions pass CPU info around as a string | ||
| // and can simply be unmarshalled by the json parser | ||
| switch t := hypervisor.CpuInfo.(type) { |
There was a problem hiding this comment.
Is there any reason this couldn't be simplified to this:
master...jrperritt:compute_hypervisors_list#diff-cf3e97a140d10e9f8115943de0bab133R93
| } | ||
|
|
||
| type HypervisorPage struct { | ||
| pagination.LinkedPageBase |
There was a problem hiding this comment.
If this is a linked page, it should have a way to get from one page to the next (usually a Links field). Does that exist?
I noticed there are Marker and Limit fields in the ListOpts, so maybe it's a MarkerPage?
There was a problem hiding this comment.
@jrperritt You are right, it's actually a marker page. Sadly when I implemented it properly it seems our version of OpenStack doesn't support the marker field (e.g. needs Nova V2.33) and just spins forever. Do we have a standard way of catering for OpenStack's API stupidity regarding backwards compatibility?
There was a problem hiding this comment.
I'm guessing lowest common denominator e.g. SinglePageBase
| VCPUsUsed int `json:"vcpus_used"` | ||
| } | ||
|
|
||
| func (h *Hypervisor) UnmarshalJSON(b []byte) error { |
There was a problem hiding this comment.
Have a look at the other UnmarshalJSON functions for style changes in this method (variable name changes).
| pagination.LinkedPageBase | ||
| } | ||
|
|
||
| func (page HypervisorPage) IsEmpty() (bool, error) { |
There was a problem hiding this comment.
Have a look at the other UnmarshalJSON functions for style changes in this method (variable name changes).
| return len(hypervisors) == 0, err | ||
| } | ||
|
|
||
| func ExtractHypervisors(p pagination.Page) ([]Hypervisor, error) { |
There was a problem hiding this comment.
Have a look at the other UnmarshalJSON functions for style changes in this method (variable name changes).
For some reason this morning storage space started to (in gophercloud only not via curl) return sizes as scientific notation
Our environment doesn't support marker pages, so go for the backwards compatible option.
| func (r *Hypervisor) UnmarshalJSON(b []byte) error { | ||
|
|
||
| type tmp Hypervisor | ||
| var s *struct { |
There was a problem hiding this comment.
@jrperritt I'm unable to find Go documentation to explain when *struct is required. All other UnmarshalJSON functions use struct. Testing with both seems to result in the same.
Is *struct required here?
There was a problem hiding this comment.
To clarify a little bit:
I can do some separate / local tests with struct and *struct and see the differences there, but it seems here, json.Unmarshal will happily take both. Just not sure if *struct should be respected here.
There was a problem hiding this comment.
Is *struct required here?
No, and we should maintain consistency with the other UnmarshalJSON methods [by changing it to a non-pointer].
|
I've cleaned this up a bit and going to resubmit this in a new PR. @spjmurray's changes will remain in the commit history. |
…updates Networking v2: Updates to openstack_networking_router_v2
Adds in support to list all available hypervisors (detailed) for applications
such as monitoring and capacity planning.
API: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/hypervisors.py#L46
Pay particular attention to line 71 where the horrible cpu_info hack is introduced
For #179