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). Taking the example of downtime reports: there used to be attempts on the list capturing details of downtime measurements for each migration and report that via QMP, probably via the stats. At that time, I was concerned that whatever we change alone the lines then we risk breaking the ABI (e.g. we move code within blackout path and it can move contribution of X from bucket B1 to B2). At that time the work was not merged. However, such things (either downtime reports, or some of the stats that are pretty much not designed for generic users, like this zerocopy success counter) would still be nice if we can collect them in QMP queries. 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. PS: we have Juraj actively looking at selftests to measure downtime contributions of live migrations. Currently we need to leverage tracepoints and parse the results. If that sounds reasonable, we could start with having MigrationInfoOptional and export downtime metrics. Thanks, -- Peter Xu
