Daniel Henrique Barboza <danielhb(a)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?