Daniel Henrique Barboza <danielhb@xxxxxxxxxxxxx> 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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
