On Tue, Mar 11, 2025 at 11:20:50AM -0400, Peter Xu wrote: > On Tue, Mar 11, 2025 at 08:13:16AM +0000, Daniel P. Berrangé wrote: > > On Mon, Mar 10, 2025 at 04:03:26PM -0400, Peter Xu wrote: > > > On Mon, Mar 10, 2025 at 07:48:16PM +0000, Daniel P. Berrangé wrote: > > > > Given this is in public API, the data needs to remain reported > > > > accurately > > > > for the whole deprecation period. IOW, the patch to qiochannel needs to > > > > preserve this data too. > > > > > > :-( > > > > > > We could potentially mark MigrationStats to be experimental as a whole and > > > declare that in deprecate.rst too, then after two releases, we can > > > randomly > > > add / remove fields as wish without always need to go through the > > > deprecation process, am I right? > > > > IMHO that would be an abuse of the process and harmful to applications > > and users consuming stats. > > Ah I just noticed that's the exact same one we included in > query-migrate.. Then yes, the stable ABI is important here. > > So for this specific case, maybe we shouldn't have exposed it in QMP from > the start. > > To me, it's a question on whether we could have something experimental and > be exposed to QMP, where we don't need to guarantee a strict stable ABI, or > a very loose ABI (e.g. we can guarantee the command exists, and with > key-value string-integer pairs, nothing else).
QMP has the ability to tag commands/fields, etc as experimental. libvirt will explicitly avoid consuming or exposing anything with an experimental tag on it. > Maybe what we need is a new MigrationInfoOptional, to be embeded into > MigrationInfo (or not), marked experimental. Then in the future whenever > we want to add some new statistics, we could decide whether it should be > part of stable ABI or not. That is not required - individual struct fields can be marked experimental. The key question is what the intended usage of the fields/stats/etc is to be. If you want it used by libvirt and mgmt apps it would need to be formally supported. If it is just for adhoc QEMU developer debugging and doesn't need libvirt / app support, then experimental is fine. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
