mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-22 12:35:17 +00:00
c615c14246
For snapshots, virsh already has a (shockingly naive [1]) client-side topological sorter with the --tree option. But as a series of REDEFINE calls must be presented in topological order, it's worth letting the server do the work for us, especially since the server can give us a topological sorting with less effort than our naive client reconstruction. [1] The XXX comment in virshSnapshotListCollect() about --tree being O(n^3) is telling; https://en.wikipedia.org/wiki/Topological_sorting is an interesting resource describing Kahn's algorithm and other approaches for O(n) topological sorting for anyone motivated to use a more elegant algorithm than brute force - but that doesn't affect this patch. For now, I am purposefully NOT implementing virsh fallback code to provide a topological sort when the flag was rejected as unsupported; we can worry about that down the road if users actually demonstrate that they use new virsh but old libvirt to even need the fallback. (The code we use for --tree could be repurposed to be such a fallback, whether or not we keep it naive or improve it to be faster - but again, no one should spend time on a fallback without evidence that we need it.) The test driver makes it easy to test: $ virsh -c test:///default ' snapshot-create-as test a snapshot-create-as test c snapshot-create-as test b snapshot-list test snapshot-list test --topological snapshot-list test --descendants a snapshot-list test --descendants a --topological snapshot-list test --tree snapshot-list test --tree --topological ' Without any flags, virsh does client-side sorting alphabetically, and lists 'b' before 'c' (even though 'c' is the parent of 'b'); with the flag, virsh skips sorting, and you can now see that the server handed back data in a correct ordering. As shown here with a simple linear chain, there isn't any other possible ordering, so --tree mode doesn't seem to care whether --topological is used. But it is possible to compose more complicated DAGs with multiple children to a parent (representing reverting back to a snapshot then creating more snapshots along those divergent execution timelines), where it is then possible (but not guaranteed) that adding the --topological flag changes the --tree output (the client-side --tree algorithm breaks ties based on alphabetical sorting between two nodes that share the same parent, while the --topological sort skips the client-side alphabetical sort and ends up exposing the server's internal order for siblings, whether that be historical creation order or dependent on a random hash seed). But even if the results differ, they will still be topologically correct. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>