0d44788fc3
Introduce a bunch of new public APIs related to backup checkpoints.
Checkpoints are modeled heavily after virDomainSnapshotPtr (both
represent a point in time of the guest), although a snapshot exists
with the intent of rolling back to that state, while a checkpoint
exists to make it possible to create an incremental backup at a later
time. We may have a future hypervisor that can completely manage
checkpoints without libvirt metadata, but the first two planned
hypervisors (qemu and test) both always use libvirt for tracking
metadata relations between checkpoints, so for now, I've deferred
the counterpart of virDomainSnapshotHasMetadata for a separate
API addition at a later date if there is ever a need for it.
Note that until we allow snapshots and checkpoints to exist
simultaneously on the same domain (although the actual prevention of
this will be in a separate patch for the sake of an easier revert down
the road), that it is not possible to branch out to create more than
one checkpoint child to a given parent, although it may become
possible later when we revert to a snapshot that coincides with a
checkpoint. This also means that for now, the decision of which
checkpoint becomes the parent of a newly created one is the only
checkpoint with no child (so while there are APIs for dealing with a
current snapshot, we do not need those for checkpoints). We may end
up exposing a notion of a current checkpoint later, but it's easier to
add stuff when proven needed than to blindly support it now and wish
we hadn't exposed it.
The following map shows the API relations to snapshots, with new APIs
on the right:
Operate on a domain object to create/redefine a child:
virDomainSnapshotCreateXML virDomainCheckpointCreateXML
Operate on a child object for lifetime management:
virDomainSnapshotDelete virDomainCheckpointDelete
virDomainSnapshotFree virDomainCheckpointFree
virDomainSnapshotRef virDomainCheckpointRef
Operate on a child object to learn more about it:
virDomainSnapshotGetXMLDesc virDomainCheckpointGetXMLDesc
virDomainSnapshotGetConnect virDomainCheckpointGetConnect
virDomainSnapshotGetDomain virDomainCheckpointGetDomain
virDomainSnapshotGetName virDomainCheckpiontGetName
virDomainSnapshotGetParent virDomainCheckpiontGetParent
virDomainSnapshotHasMetadata (deferred for later)
virDomainSnapshotIsCurrent (no counterpart, see note above)
Operate on a domain object to list all children:
virDomainSnapshotNum (no counterparts, these are the old
virDomainSnapshotListNames racy interfaces)
virDomainSnapshotListAllSnapshots virDomainListAllCheckpoints
Operate on a child object to list descendents:
virDomainSnapshotNumChildren (no counterparts, these are the old
virDomainSnapshotListChildrenNames racy interfaces)
virDomainSnapshotListAllChildren virDomainCheckpointListAllChildren
Operate on a domain to locate a particular child:
virDomainSnapshotLookupByName virDomainCheckpointLookupByName
virDomainSnapshotCurrent (no counterpart, see note above)
virDomainHasCurrentSnapshot (no counterpart, old racy interface)
Operate on a snapshot to roll back to earlier state:
virDomainSnapshotRevert (no counterpart, instead checkpoints
are used in incremental backups via
XML to virDomainBackupBegin)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt Message Translation
Libvirt translatable messages are maintained using the GNU Gettext tools and file formats, in combination with the Zanata web service.
Source repository
The libvirt GIT repository does NOT store the master "libvirt.pot" file, nor does it store full "po" files for translations. The master "libvirt.pot" file can be generated at any time using
make libvirt.pot
The translations are kept in minimized files that are the same file format as normal po files but with all redundant information stripped and messages re-ordered. The key differences between the ".mini.po" files in GIT and the full ".po" files are
- msgids with no current translation are omitted
- msgids are sorted in alphabetical order not source file order
- msgids with a msgstr marked "fuzzy" are discarded
- source file locations are omitted
The full po files can be created at any time using
make update-po
This merges the "libvirt.pot" with the "$LANG.mini.po" for each language, to create the "$LANG.po" files. These are included in the release archives created by "make dist".
When a full po file is updated, changes can be propagated back into the minimized po files using
make update-mini-po
Note, however, that this is generally not something that should be run by developers normally, as it is triggered by 'make pull-po' when refreshing content from Zanata.
Zanata web service
The translation of libvirt messages has been outsourced to the Fedora translation team using the Zanata web service:
https://fedora.zanata.org/project/view/libvirt
As such, changes to translations will generally NOT be accepted as patches directly to libvirt GIT. Any changes made to "$LANG.mini.po" files in libvirt GIT will be overwritten and lost the next time content is imported from Zanata.
The master "libvirt.pot" file is periodically pushed to Zanata to provide the translation team with content changes, using
make push-pot
New translated text is then periodically pulled down from Zanata to update the minimized po files, using
make pull-po
Sometimes the translators make mistakes, most commonly with handling printf format specifiers. The "pull-po" command re-generates the .gmo files to try to identify such mistakes. If a mistake is made, the broken msgstr should be deleted in the local "$LANG.mini.po" file, and the Zanata web interface used to reject the translation so that the broken msgstr isn't pulled down next time.
After pulling down new content the diff should be examined to look for any obvious mistakes that are not caught automatically. There have been bugs in Zanata tools which caused messges to go missing, so pay particular attention to diffs showing deletions where the msgid still exists in libvirt.pot