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
