On 13.10.2016 00:46, John Ferlan wrote: [...]
Despite fixing user strings in this version to show the word 'running' the enum value [1] is still changed for the new one. Since the actual value is used by programs and not humans that may break and I'm not comfortable allowing such change in semantics.
Hm, really? From an API perspective up to now it was perfectly OK to accept any of "offline", "running" and "blocked". I maintain that it is valid to extend the state enumeration and virsh shows how to handle previously unknown states.
I think the objection is for the vcpuinfo command which shouldn't need to be CPU aware, but perhaps similar to how aware the hotplug code had to be made for the differences between arch's, maybe the info code needs that as well (as ugly as that could be). I'm just trying to throw some suggestions out there to see if anything sticks.
It's painful that the "halted" bit has multiple meanings, but I think it's handle-able - we just have to find the right way to do it...
I think it's not libvirt's task to interpret the meaning of halted as reported by QEMU. That's why I added the new state in the first place instead of reusing e.g. offline, which would have introduced architecture depend code which I'd like to avoid where possible.
Another "thought" that strikes me is whether there's a "valid" scenario where someone can halt a CPU from the guest and how that gets propagated back - even on x86. OK it's a slight divergence...
While I did suggest some sort of running (halted) output, does seeing that on for a non x86 guest make sense for the state the CPU is in? In a former job, I think we called it "running (idle)" mainly because "halted" has a somewhat negative connotation.
So another option might be to allow a vcpuinfo user to pass a new flag that would allow that return of this more detailed state. Only if the flag was set would we check/return the new state. I think that's what we've done in the past for similar things where changing the "default" return/display value could cause "issues" for those programs that rely on the string being "running" without " (halted)" or " (idle)". Does this make sense?
In essence that would mean to implement a new API, which seems to be too heavy a hammer for this small nail.
Then for the other (stats) output, returning the value of the "halted" field could be an "additional" set of output/data to be added rather than overloading the existing field. Does this make sense?
That's what I'll do, expect a new series soon... [...]
And, if you find value in the virsh.pod update in 1/4, you can either pick the parts you need or let me know and I can provide an abridged version. [...]
I do like the adjustments made to virsh.pod.
There you go...
John
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294