From: "Max Carrara" <m.carrara@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v1 pve-storage 6/8] pluginbase: document image operation methods
Date: Wed, 02 Apr 2025 18:32:01 +0200 [thread overview]
Message-ID: <D8WAP6RU0D56.1T3QC7BCQI5D7@proxmox.com> (raw)
In-Reply-To: <1743430815.p3lidgbz0m.astroid@yuna.none>
On Mon Mar 31, 2025 at 5:12 PM CEST, Fabian Grünbichler wrote:
> On March 26, 2025 3:20 pm, Max Carrara wrote:
> > Add documentation for the following methods:
> > - list_images
> > - create_base
> > - clone_image
> > - alloc_image
> > - free_image
> >
> > Signed-off-by: Max Carrara <m.carrara@proxmox.com>
> > Co-authored-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> > ---
> > src/PVE/Storage/PluginBase.pm | 111 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 111 insertions(+)
> >
> > diff --git a/src/PVE/Storage/PluginBase.pm b/src/PVE/Storage/PluginBase.pm
> > index b3ce684..37b1471 100644
> > --- a/src/PVE/Storage/PluginBase.pm
> > +++ b/src/PVE/Storage/PluginBase.pm
> > @@ -721,26 +721,137 @@ sub on_delete_hook {
> >
> > =cut
> >
> > +=head3 $plugin->list_images($storeid, \%scfg [, $vmid, \@vollist, \%cache])
> > +
> > +B<REQUIRED:> Must be implemented in every storage plugin.
> > +
> > +Returns a listref of all disk images of a storage. If the storage does not
> > +support storing disk images, returns an empty listref.
> > +
> > +Optionally, if C<\@vollist> is provided, return only disks whose volume ID is
> > +within C<\@vollist>. Note that this usually has higher precedence than
> > +C<$vmid>.
Upfront note: Unless I otherwise comment something, I agree with you.
Just sparing myself from writing and you from reading too many ACKs :P
>
> what does usually mean? what does $vmid do?
Sorry, this got lost when tossing out some redundant paragraphs here.
The "usually" can be dropped; C<$vmid> is the guest's ID (mentioned in
the DESCRIPTION in patch 01) and unless C<\@vollist> is provided, the
images that the given C<$vmid> owns will be returned.
>
> > +
> > +C<die>s in case of errors.
> > +
> > +This method may reuse L<< cached information via C<\%cache>|/"CACHING EXPENSIVE OPERATIONS" >>.
> > +
> > +The returned listref has the following structure:
> > +
> > + [
> > + {
> > + ctime => "1689163322", # creation time as unix timestamp
> > + format => "raw",
> > + size => 8589934592, # in bytes!
> > + vmid => 101,
> > + volid => "local-lvm:base-101-disk-0", # volume ID, storage-specific
> > + },
> > + # [...]
> > + ]
> > +
> > +=cut
> > +
> > sub list_images {
> > my ($class, $storeid, $scfg, $vmid, $vollist, $cache) = @_;
> > croak "implement me in sub-class\n";
> > }
> >
> > +=head3 $plugin->create_base($storeid, \%scfg, $volname)
> > +
> > +B<OPTIONAL:> May be implemented in a storage plugin.
> > +
> > +Creates a base volume from an existing volume, allowing the volume to be
>
> this is misleading - it doesn't create a base volume from an existing
> volume, it *converts* an existing volume into a base volume!
Oh dang, thanks for pointing this out! Sorry for the oversight.
>
> > +L<< cloned|/"$plugin->clone_image(...)" >>. This cloned volume (usually
> > +a disk image) may then be used as a base for the purpose of creating linked
>
> this is wrong? there is no cloned volume yet? and all of this only
> applies to images and not other volumes?
>
> > +clones. See L<C<PVE::Storage::LvmThinPlugin>> and
> > +L<C<PVE::Storage::ZFSPoolPlugin>> for example implementations.
> > +
> > +On completion, returns the name of the new base volume (the new C<$volname>).
> > +
> > +This method is called in the context of C<L<< cluster_lock_storage()|/"cluster_lock_storage(...)" >>>,
> > +i.e. when the storage is B<locked>.
>
> Shouldn't this say that it *should* be called in a locked context?
>
> > +
> > +=cut
> > +
> > sub create_base {
> > my ($class, $storeid, $scfg, $volname) = @_;
> > croak "implement me in sub-class\n";
> > }
> >
> > +=head3 $plugin->clone_image($scfg, $storeid, $volname, $vmid [, $snap])
> > +
> > +=head3 $plugin->clone_image(...)
> > +
> > +B<REQUIRED:> Must be implemented in every storage plugin.
>
> not really? there's a feature guard for it, so only storage plugins that
> support it should ever get it called anyway..
>
> what does $vmid mean?
See above; the guest's ID. Since it was unclear, the parameter should
probably be explained here (and also above) instead of (just) in the
DESCRIPTION section.
>
> > +
> > +Clones a disk image or a snapshot of an image, returning the name of the new
> > +image (the new C<$volname>). Note that I<cloning> here means to create a linked
> > +clone and not duplicating an image. See L<C<PVE::Storage::LvmThinPlugin>> and
> > +L<C<PVE::Storage::ZFSPoolPlugin>> for example implementations.
>
> then why not start with
>
> "Creates a linked clone of an existing disk image or snapshot of an
> image"
>
> ? maybe also include that unless the linked clone is 100% independent
> from the base (only true for LVM thin atm?), the new volid should encode
> the base->clone relation in the volname?
>
> > +
> > +C<die>s in case of an error of if the underlying storage doesn't support
>
> s/of/or/
>
> > +cloning images.
> > +
> > +This method is called in the context of C<L<< cluster_lock_storage()|/"cluster_lock_storage(...)" >>>,
> > +i.e. when the storage is B<locked>.
>
> same as above
>
> > +
> > +=cut
> > +
> > sub clone_image {
> > my ($class, $scfg, $storeid, $volname, $vmid, $snap) = @_;
> > croak "implement me in sub-class\n";
> > }
> >
> > +=head3 $plugin->alloc_image($storeid, $scfg, $vmid, $fmt, $name, $size)
> > +
> > +B<REQUIRED:> Must be implemented in every storage plugin.
> > +
> > +Allocates a disk image with the given format C<$fmt> and C<$size> in bytes,
> > +returning the name of the new image (the new C<$volname>). See
> > +C<L<< plugindata()|/"$plugin->plugindata()" >>> for all disk formats.
> > +
> > +Optionally, if given, set the name of the image to C<$name>. If C<$name> isn't
> > +provided, the next name should be determined via C<L<< find_free_diskname()|/"$plugin->find_free_diskname(...)" >>>.
>
> a suitable name should be automatically generated, unless we really want
> to stabilize find_free_diskname as part of the API..
>
> what does $vmid mean?
>
> > +
> > +C<die>s in case of an error of if the underlying storage doesn't support
> > +allocating images.
> > +
> > +This method is called in the context of C<L<< cluster_lock_storage()|/"cluster_lock_storage(...)" >>>,
> > +i.e. when the storage is B<locked>.
> > +
> > +=cut
> > +
> > sub alloc_image {
> > my ($class, $storeid, $scfg, $vmid, $fmt, $name, $size) = @_;
> > croak "implement me in sub-class\n";
> > }
> >
> > +=head3 $plugin->free_image($storeid, $scfg, $volname [, $isBase, $format])
> > +
> > +=head3 $plugin->free_image(...)
> > +
> > +B<REQUIRED:> Must be implemented in every storage plugin.
> > +
> > +Frees (deletes) the disk image given by C<$volname>. Optionally, the image may
> > +be a base image (C<$isBase>) and have a certain C<$format>. See
> > +C<L<< plugindata()|/"$plugin->plugindata()" >>> for all disk formats.
> > +
> > +If a cleanup is required after freeing the image, returns a reference to a
> > +subroutine that performs the cleanup, and C<undef> otherwise.
>
> might be a good idea to explain why? also, what do $isBase and $format
> mean?
>
> > +
> > +C<die>s in case of errors, if the image has a L<< C<protected> attribute|/"$plugin->get_volume_attribute(...)" >>
> > +(and may thus not be freed), or if the underlying storage implementation
> > +doesn't support freeing images.
> > +
> > +This method is called in the context of C<L<< cluster_lock_storage()|/"cluster_lock_storage(...)" >>>,
> > +i.e. when the storage is B<locked>.
> > +
> > +B<NOTE:> The returned cleanup subroutine is called in a separate worker and
> > +should L<< lock|/"$plugin->cluster_lock_storage(...)" >> the underlying storage
> > +separately.
>
> it should? or it must?
>
> > +
> > +=cut
> > +
> > sub free_image {
> > my ($class, $storeid, $scfg, $volname, $isBase, $format) = @_;
> > croak "implement me in sub-class\n";
> > --
> > 2.39.5
> >
> >
> >
> > _______________________________________________
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> >
> >
> >
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-04-02 16:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 14:20 [pve-devel] [PATCH v1 pve-storage 0/8] Base Module + Documentation for PVE::Storage::Plugin API Max Carrara
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 1/8] pluginbase: introduce PVE::Storage::PluginBase with doc scaffold Max Carrara
2025-03-31 15:13 ` Fabian Grünbichler
2025-04-02 16:31 ` Max Carrara
2025-04-03 7:12 ` Fabian Grünbichler
2025-04-03 14:05 ` Max Carrara
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 2/8] pluginbase: add high-level plugin API description Max Carrara
2025-03-31 15:13 ` Fabian Grünbichler
2025-04-02 16:31 ` Max Carrara
2025-04-03 7:12 ` Fabian Grünbichler
2025-04-03 14:05 ` Max Carrara
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 3/8] pluginbase: document SectionConfig methods Max Carrara
2025-03-31 15:13 ` Fabian Grünbichler
2025-04-02 16:31 ` Max Carrara
2025-04-11 13:49 ` Wolfgang Bumiller
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 4/8] pluginbase: document general plugin methods Max Carrara
2025-03-28 12:50 ` Maximiliano Sandoval
2025-03-31 15:12 ` Fabian Grünbichler
2025-04-02 16:31 ` Max Carrara
2025-04-11 14:04 ` Wolfgang Bumiller
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 5/8] pluginbase: document hooks Max Carrara
2025-03-28 13:07 ` Maximiliano Sandoval
2025-03-31 15:12 ` Fabian Grünbichler
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 6/8] pluginbase: document image operation methods Max Carrara
2025-03-31 15:12 ` Fabian Grünbichler
2025-04-02 16:32 ` Max Carrara [this message]
2025-04-03 7:23 ` Fabian Grünbichler
2025-04-03 14:05 ` Max Carrara
2025-04-11 14:08 ` Wolfgang Bumiller
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 7/8] pluginbase: document volume operations Max Carrara
2025-03-31 15:12 ` Fabian Grünbichler
2025-04-02 16:32 ` Max Carrara
2025-04-14 8:24 ` Wolfgang Bumiller
2025-03-26 14:20 ` [pve-devel] [PATCH v1 pve-storage 8/8] pluginbase: document import and export methods Max Carrara
2025-04-01 8:40 ` Fabian Grünbichler
2025-04-01 9:40 ` Fiona Ebner
2025-04-14 14:35 ` Wolfgang Bumiller
2025-04-02 16:32 ` Max Carrara
2025-04-11 13:27 ` [pve-devel] [PATCH v1 pve-storage 0/8] Base Module + Documentation for PVE::Storage::Plugin API Wolfgang Bumiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D8WAP6RU0D56.1T3QC7BCQI5D7@proxmox.com \
--to=m.carrara@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal