--- Begin Message ---
On Wed, Mar 13, 2024 at 04:38:57PM +0100, Wolfgang Bumiller wrote:
> My thoughts on this: (TLDR: we should just merge it and probably also
> consider adding a separate method to get the *format* of a volid)
>
> - Adding the parameter itself is fine, not thinking about how/why
On Tue, Mar 05, 2024 at 12:13:05PM +0100, Thomas Lamprecht wrote:
> Am 23/02/2024 um 10:24 schrieb Roland Kammerer:
> > This passes the well known $scfg to parse_volname and bumps the API
> > versions accordingly. This allows plugins to access their configuration
> > if necessary.
>
> We discussed
--- Begin Message ---
On Tue, Mar 05, 2024 at 01:13:08PM +0100, Fabian Grünbichler wrote:
> I wonder whether the following wouldn't also work?
>
> - keep the volume name on the PVE side like the other storage plugins
> (which means - encode vital information about the volume there so that
> it's p
Roland Kammerer wrote:
> On Thu, Feb 29, 2024 at 02:29:51PM +0100, Fiona Ebner wrote:
> > Am 23.02.24 um 10:24 schrieb Roland Kammerer:
> > > This passes the well known $scfg to parse_volname and bumps the API
> > > versions accordingly. This allows plugins to access their configuration
> > > if ne
Am 23/02/2024 um 10:24 schrieb Roland Kammerer:
> This passes the well known $scfg to parse_volname and bumps the API
> versions accordingly. This allows plugins to access their configuration
> if necessary.
We discussed this another time here and effectively it can be fine, while
the need for it
--- Begin Message ---
On Fri, Mar 01, 2024 at 11:14:31AM +0100, Roland Kammerer wrote:
> On Fri, Mar 01, 2024 at 10:45:37AM +0100, Dietmar Maurer wrote:
> >
> > > On 29.2.2024 16:09 CET Roland Kammerer via pve-devel
> > > wrote:
> > > All in all, yes, this is specific for our use case, otherwise
--- Begin Message ---
On Fri, Mar 01, 2024 at 10:45:37AM +0100, Dietmar Maurer wrote:
>
> > On 29.2.2024 16:09 CET Roland Kammerer via pve-devel
> > wrote:
> > All in all, yes, this is specific for our use case, otherwise
> > parse_volname would already have that additional parameter as all the
> On 29.2.2024 16:09 CET Roland Kammerer via pve-devel
> wrote:
> All in all, yes, this is specific for our use case, otherwise
> parse_volname would already have that additional parameter as all the
> other plugin functions, but I don't see where this would hurt existing
> code, and it certain
--- Begin Message ---
On Thu, Feb 29, 2024 at 02:29:51PM +0100, Fiona Ebner wrote:
> Am 23.02.24 um 10:24 schrieb Roland Kammerer:
> > This passes the well known $scfg to parse_volname and bumps the API
> > versions accordingly. This allows plugins to access their configuration
> > if necessary.
>
Am 23.02.24 um 10:24 schrieb Roland Kammerer:
> This passes the well known $scfg to parse_volname and bumps the API
> versions accordingly. This allows plugins to access their configuration
> if necessary.
>
Hi,
can you please describe your use case in more detail? Why does parsing
the volume nam
--- Begin Message ---
On Fri, Feb 23, 2024 at 10:24:36AM +0100, Roland Kammerer wrote:
> This passes the well known $scfg to parse_volname and bumps the API
> versions accordingly. This allows plugins to access their configuration
> if necessary.
Hi devs,
just a ping as this did not get any feedb
--- Begin Message ---
This passes the well known $scfg to parse_volname and bumps the API
versions accordingly. This allows plugins to access their configuration
if necessary.
Signed-off-by: Roland Kammerer
---
ApiChangeLog | 7 +++
src/PVE/Storage.pm | 18 +-
2 files
12 matches
Mail list logo
