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.
2021-10-19 10:54:52 +03:00
## Version 10:
2021-11-09 17:55:32 +03:00
* 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.
2021-10-19 10:54:52 +03:00
* 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.
2021-11-09 14:29:48 +03:00
* 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.
2021-10-19 10:54:52 +03:00