On Wed, Jan 16, 2019 at 03:46:12PM +0100, Andrea Bolognani wrote: > On Wed, 2019-01-16 at 14:19 +0000, Daniel P. Berrangé wrote: > > On Wed, Jan 16, 2019 at 03:07:07PM +0100, Andrea Bolognani wrote: > > > On Wed, 2019-01-16 at 11:13 +0000, Daniel P. Berrangé wrote: > > > > The enum should cover all existing reasonably expected configs. Sure I > > > > imagine we might miss a few, especially for obscure architectures or > > > > hypervisors, but that would just be bugs to be fixed > > > > > > Until we've fixed said bugs, guests using such models would just > > > disappear though, wouldn't they? That doesn't sound acceptable. > > > > We could do a multi-step conversion. First define an enum and report > > all known enum values in the domain capabilities. Taint any guest > > using a nic with doesn't match. A year or so later, then finally > > enforce the enum usage. > > That will still result in guests disappearing at some point, which > is not something that we're generally okay with. Why would it be > any different this time around? No change we make is perfectly risk free. We would want to have reasonable confidence that the initial enum is a good as we can practically make it. The tainting check & log is a way to identify if we made some mistakes - hopefully we won't have. If users do report it though, we'll be able to fix it. If we get no reports for a reasonable period of time (minimum 12 months), it is OK to assume we've not broken anything that we believe has users. > > > And defining even the incomplete enum would require someone to > > > be familiar with all drivers in order to know which models are > > > commonly used, or at all available. > > > > It isn't as bad as it seems. VMWare has whitelisted names, Hyperv > > doesn't report models at all, Xen is a small finite set. QEMU is > > the only hard one given the huge set of system emulators. > > If we're willing to leave some theoretical users of impractical > network devices in the dust, then coming up with a reasonably small > list for QEMU is not too difficult either... But see above :) The QEMU list won't be small - it'll be large given all archs ! 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
