Re: [libvirt] [PATCH 1/8] snapshots: Avoid term 'checkpoint' for full system snapshot

On 06/25/2018 06:27 PM, Eric Blake wrote: Understood - since I've made it further now. Domain state is somewhat of a tangled or interwoven part of the domain XML lifecycle fabric, so I perhaps process it that way when reading new code. It seems the design is that XML for domain{checkpoint|backup} will be similar to domainstatus, but far more restrictive to the specific needs for each since you're saving the original config in the output. I saw things as more of "{Create|Start|Set|Clear|End|Destroy}" type operations initially, but I've gone through my viewpoint has changed. I'm still concerned with over complicating with too many flags which is where we seem to have gotten ourselves in trouble with snapshot as time went on and more or less functionality points were desired. Checkpoint/backup is complex enough without adding levels of features for consumers that may or may not be used. In the long run, it's where do you give up control and how much can/should be assumed to be libvirt's "job". If a consumer wants to do something particularly tricky, then maybe we should just hand them the gun with one bullet in the chamber (so to speak). Provide an API that "locks out" other threads instead of doing that for them ;-) - someone always thinks they can do it better! In the long run, we don't necessarily know how all consumers would like to use this and so far there's been mixed opinions on what should be done. At some level the operation of starting checkpoints, setting checkpoints, and allowing/performing backups from a specific checkpoint are fairly straightforward type operations. It's the additional cruft and flags to do "fancy" stuff or the desire to worry about every possible operation option someone could possibly want that I think causes over complication. Let the up-the-stack app keep track of things if that's the complicated level they desire. Keep the libvirt side simple. I think so, but I haven't reached the Backup API's yet. There's the interaction with NBD that's going to keep things "interesting". Reminding myself that under the covers, migrations start/stop an NBD server is I assume the impetus behind [re]using NBD as the 3rd party integration point. Perhaps something that becomes part of the documentation description for describing the difference between pull/push backup models. OK - it's not 100% clear in my mind all the various pieces needed for this to all work properly. I understand the desire/need for inclusion; however, we do need to consider that in more recent times "waiting" for a more functional solution to be "ready" in QEMU before pushing libvirt changes - especially ones that bake an API... Understood. John