On Wed, Mar 06, 2019 at 09:30:32AM +0100, Ján Tomko wrote:
On Wed, Mar 06, 2019 at 08:41:48AM +0100, Peter Krempa wrote:
On Tue, Mar 05, 2019 at 16:56:43 +0100, Andrea Bolognani wrote:
On Tue, 2019-03-05 at 15:38 +0100, Gerd Hoffmann wrote:
[...]
So I agree neither scenario is exactly perfect, but I still think adding non-transitional alias devices would overall be more user-friendly.
I don't think it makes sense to add it at the qemu level. From libvirt's point of view users should be shielded from any qemu impl detail or inconsistency as libvirt is the 'user friendly'[1] layer. In qemu the devices would be the same and thus does not make sense to do that because it would be more confusing.
You can argue that we should add the alias at the libvirt level though.
You can, but please don't.
Indeed, at the libvirt level we've always tried to take the view that there should be one way to expressing each concept/feature. Adding new names / xml elements that duplicate existing supported concepts to make things "consistent" is a slippery slope becasue there are 100's of places to which that can apply when you have hindsight. It is not going to make a significant difference to how "user friendly" libvirt is - that is not a core goal in its own right at the API / XML schema level. It is can be a factor in deciding between multiple competing designs when first adding a feature, but it isn't a reason to add duplication in the API / XML. 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 :|