5
0
mirror of git://git.proxmox.com/git/pve-storage.git synced 2025-01-05 09:17:59 +03:00
pve-storage/ApiChangeLog

52 lines
2.0 KiB
Plaintext
Raw Normal View History

bump storage API: update import/export methods Bumps APIVER to 9 and resets APIAGE to zero. The import methods (volume_import, volume_import_formats): These additionally get the '$snapshot' parameter which is already present on the export side as an informational piece to know which of the snapshots is the *current* one. This parameter is inserted *in the middle* of the current parameters, so the import & export format methods now have the same signatures. The current "disk" state will be set to this snapshot. This, too, is required for our btrfs implementation. `volume_import_formats` can obviously not make much *use* of this parameter, but it'll still be useful to know that the information is actually available in the import call, so its presence will be checked in the btrfs implementation. Currently this is intended to be used for btrfs send/recv support, which in theory could also get additional metadata similar to how we do the "tar+size" format, however, we currently only really use this within this repository in storage_migrate() which has this information readily available anyway. On the export side (volume_export, volume_export_formats): The `$with_snapshots` option is now "defined" to be an ordered array of snapshots to include, as a hint for storages which need this. (As of the next commit this is only btrfs, and only when also specifying a base snapshot, which is a case we can currently not run into except on the command line interface.) The current providers of the `with_snapshot` option will still treat it as a boolean (since eg. for ZFS you cannot really "skip" snapshots AFAIK). This is mainly intended for storages which do not have a strong association between snapshots and the originals, or an ordering (eg. btrfs and lvm-thin allow creating arbitrary snapshot trees, and with btrfs you can even create a "circular" connection between subvolumes, also we could consider reflink based copies snapshots on xfs in the future maybe?) Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
2021-06-22 15:18:21 +03:00
# API Versioning ChangeLog
Our API versioning contains an `APIVER` and an `APIAGE`.
The `APIAGE` is the number of versions we're backward compatible with. (iow. things got added
without breaking anything unaware of it.)
Future changes should be documented in here.
## Version 10:
* a new `rename_volume` method has been added
Storage plugins with rename support need to enable
the `rename` feature flag; e.g. in the `volume_has_feature` method.
* Replace `volume_snapshot_list` with `volume_snapshot_info`:
`volume_snapshot_list` was used exclusively by replication and currently, replication is only
allowed for the storage type `zfspool`. Thus, no external plugins should be affected by this
change and `APIAGE` is *not* reset.
`volume_snapshot_info` returns a hash with snapshot names as keys and `id` and `timestamp` data
for each snapshot, rather than just an array of snaphsot names like `volume_snapshot_list` did.
* Add `blockers` parameter to `volume_rollback_is_possible`:
The parameter *can* be used to return a list of snapshots that is currently preventing rollback.
* Replace get/update_volume_notes with generic get/update_volume_attribute
falling back to the old implementation for notes until we reset APIAGE. the
new method optionally also supports querying/setting a protected flag.
bump storage API: update import/export methods Bumps APIVER to 9 and resets APIAGE to zero. The import methods (volume_import, volume_import_formats): These additionally get the '$snapshot' parameter which is already present on the export side as an informational piece to know which of the snapshots is the *current* one. This parameter is inserted *in the middle* of the current parameters, so the import & export format methods now have the same signatures. The current "disk" state will be set to this snapshot. This, too, is required for our btrfs implementation. `volume_import_formats` can obviously not make much *use* of this parameter, but it'll still be useful to know that the information is actually available in the import call, so its presence will be checked in the btrfs implementation. Currently this is intended to be used for btrfs send/recv support, which in theory could also get additional metadata similar to how we do the "tar+size" format, however, we currently only really use this within this repository in storage_migrate() which has this information readily available anyway. On the export side (volume_export, volume_export_formats): The `$with_snapshots` option is now "defined" to be an ordered array of snapshots to include, as a hint for storages which need this. (As of the next commit this is only btrfs, and only when also specifying a base snapshot, which is a case we can currently not run into except on the command line interface.) The current providers of the `with_snapshot` option will still treat it as a boolean (since eg. for ZFS you cannot really "skip" snapshots AFAIK). This is mainly intended for storages which do not have a strong association between snapshots and the originals, or an ordering (eg. btrfs and lvm-thin allow creating arbitrary snapshot trees, and with btrfs you can even create a "circular" connection between subvolumes, also we could consider reflink based copies snapshots on xfs in the future maybe?) Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
2021-06-22 15:18:21 +03:00
## Version 9: (AGE resets to 0):
* volume_import_formats gets a new parameter *inserted*:
Old signature:
sub($plugin, $scfg, $storeid, $volname, $base_snapshot, $with_snapshots)
New signature:
sub($plugin, $scfg, $storeid, $volname, $snapshot, $base_snapshot, $with_snapshots)
This is now the same as `volume_export_formats`.
The same goes for calls to `PVE::Storage::volume_import_formats`, which now
takes a `$snapshot` parameter in the same place.
* $with_snapshots *may* now be an array reference containing an ordered list of
snapshots, but *may* also just be a boolean, and the contained list *may* be
ignored, so it can still be treated as a boolean.