Daniel Henrique Barboza <danielhb@linux.ibm.com> writes:
Hi,
Sorry for the delay. I'll summarize what I've understood from the discussion so far:
- query-target is the wrong place for this flag. query-machines is (less) wrong because it is not a static property of the machine object
- a new "query-current-machine" can be created to host these dynamic properties that belongs to the current instance of the VM
- there are machines in which the suspend support may vary with a "-no-acpi" option that would disable both the suspend and wake-up support. In this case, I see no problem into counting this flag into the logic (assuming it is possible, of course) and setting it as "false" if there is -no-acpi present (or even making the API returning "yes", "no" or "acpi" like Markus suggested) somewhere.
Based on the last email from Eduardo, apparently there is a handful of other machine properties that can be hosted in either this new query-current-machine API or query-machines. I believe that this is more of a long term goal, but this new query-current-machine API would be a good kick-off and we should go for it.
Is this a fair understanding? Did I miss something?
Sounds fair to me. Adding query-current-machine on the evidence of just one flag would be questionable, but Eduardo expects there to be more, so it's okay. Whether a property is static or dynamic can change over time, which makes the choice of query-machines vs. query-current-machine non-trivial. We better write down how we plan to handle mispredictions, i.e. what to do when a property we put into query-machines turns out to be dynamic, or a property we put into query-current-machine turns out to be static, or we'd like query-machines to cover a property that is static except for a few machines. Eduardo, anything to add?