On 22 Mar 2018, at 10:37, Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Mar 22, 2018 at 09:40:40AM +0100, Pavel Hrdina wrote:
On Tue, Mar 20, 2018 at 03:10:12PM +0000, Daniel P. Berrangé wrote:
- I understand OpenStack has some really sensible and wisely chosen
and/or tested default values.
In terms of default devices and OS specific choices, OpenStack's decisions have been largely inspired by previous work in oVirt and / or virt-manager. So there's obviously overlap in the conceptual area, but there's also plenty that is very specific to OpenStack - untangling the two extract the common bits from the app specific bits is hard.
This would be handled by the application specific policies. The virtuned will have some reasonable defaults that are known to work in most cases and suits the majority of users, but it's clear that sometimes you need some specific defaults and you would provide them via the application policy.
For example, to create a XML for windows guest the virtuned would not probably select virtio devices because there are no drivers for them in the standard windows installation, however, some management application may have customized preinstalled disk images or customized ISO images or it may be able to provide the drivers any other way, so they would specify in the application policy that for windows guest virtuned should use virtio as a default device model.
As soon as we talk about configuring hardware specific to a guest OS, then that is in scope of existing libosinfo project, not something we should create a new project for.
This is probably the hardest part of creating higher level API on top of libvirt, not every project may be willing to rewrite their existing code. On the other hand, I know that for example Cockpit would benefit from the virtuned providing this functionality via REST API.
It's a chicken and egg problem, but if we can gather input from all the existing projects that have their own implementation and figure out how to make virtuned usable for all of them they might consider to start using it.
I don't doubt that Cockpit would like like, but based on previous efforts we've made I'm sceptical that anything beyond Cockpit would use any new API.
We have an opportunity to make kubevirt right, too. Sure, the project is halfway through with own presets and custom code (just repeating oVirt and Openstack), but it’s not too late to change things there, and a remote API fits well
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 :|
-- You received this message because you are subscribed to the Google Groups "kubevirt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev+unsubscribe@googlegroups.com. To post to this group, send email to kubevirt-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/20180322093722.GB3583%40redha.... For more options, visit https://groups.google.com/d/optout.