On Wed, Jan 16, 2019 at 15:36:29 +0000, Daniel Berrange wrote: > 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. You can introduce yet another intermediate stage where the Validation machinery will reject to start and define VMs with invalid names. That way you get a way stronger level of user warning than taints are with the benefit of not losing guests at that point.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
