Re: [PATCH v9 4/7] qapi: add blockdev-replace command

[Kevin Wolf <kwolf@redhat.com>]

Am 18.11.2025 um 08:37 hat Vladimir Sementsov-Ogievskiy geschrieben:
> On 17.11.25 13:49, Kevin Wolf wrote:
> > Hi Vladimir,
> > 
> > I remembered this series and wanted to check what the current status is,
> > because I seemed to remember that the next step was that you would send
> > a new version. But reading it again, you're probably waiting for more
> > input? Let's try to get this finished.
> 
> I think yes, I was waiting, but then switched to other tasks.
> 
> > 
> > Am 02.04.2025 um 15:05 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > On 18.10.24 16:59, Kevin Wolf wrote:
> > > > If we want to get rid of the union, I think the best course of action
> > > > would unifying the namespaces (so that nodes, exports and devices can't
> > > > share the same ID) and then we could just accept a universal 'id' along
> > > > with 'child'.
> > > 
> > > Maybe we can go this way even without explicit restriction (which
> > > should some how go through deprecation period, etc), but simply look
> > > for the id among nodes, devices and exports and if found more than one
> > > parent - fail.
> > > 
> > > And we document, that id should not be ambiguous, should not match more
> > > than one parent object. So, those who want to use new command will care
> > > to make unique ids.
> > 
> > I don't think such a state is very pretty, but it would be okay for me
> > as an intermediate state while we go through a deprecation period to
> > restrict IDs accordingly.
> > 
> > So we could start with blockdev-replace returning an error on ambiguous
> > IDs and at the same time deprecate them, and only later we would make
> > creating nodes/devices/exports with the same ID an error.
> > 
> 
> Hmm, the only question remains, is what/how to deprecate exactly?
> 
> We want to deprecate user's possibility to set intersecting
> IDs for exports / devices / block-nodes? I think, we don't
> have a QAPI-native way to deprecate such thing..

We don't have to be able to express every deprecation in the schema. If
it can be expressed, that's nice, but docs/about/deprecated.rst is the
important part.

> May be, add new "uuid" parameter, and deprecate its absence (I doubt
> that we can do such deprecation too). And deprecate old IDs? But we
> can't deprecate QOM path for this..

I don't think renaming options is necessary.

> Hmm, or move to QOM paths for block-nodes and exports? And deprecate
> export names and node names?

That would only make sense if we converted the block layer to a QOM
class hierarchy, which would be a project of its own.

> Or we can just deprecate intersecting IDs in documentation and start
> to print warning, when user make intersecting IDs? But nobody reads
> warnings..
> 
> Is there a proper way to deprecate such things?

The latter is what I would suggest. docs/about/deprecated.rst and
printing warnings. I think libvirt already keeps all IDs distinct
anyway, so for a large part of users nothing will change.

Kevin