> My view on what profiles are for differs from this. In particular > I do *not* consider the profiles to be application specific. Oh, I think we are talking about different applications. I agree all management products (the applications you talk about) should use the same data. But workload profiles are about guest application specific needs (the apps I talk about) and pure osinfo is about guest application independent guest os defaults. Here the application means the app running within the VM. Martin On Tue, Jan 22, 2019 at 3:08 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Tue, Jan 22, 2019 at 02:56:44PM +0100, Martin Sivak wrote: > > > - Revisit Features/Timers after having a clear idea about the Profiles > > > work started by Martin Kletzander. > > > > > > Does that sound like a deal? > > > > Except the workload profiles are trying to solve a different thing > > there (application specific needs on top of guest OS). > > > > Pure libOSinfo is about what a guest OS supports and what the > > application _independent_ defaults for the guest OS should be. And the > > timers are mostly that (at least RHV always used them like that). The > > features we want are 100% that and have definitely nothing to do with > > workload profiles. Some of that information is architecture dependent > > though but libosinfo apparently knows how to handle this aspect > > already. > > > > Hypervisor feature support has also nothing to do with workload > > profiles and maybe we need a separate database for hypervisor features > > :) > > > > For those reasons I would gently ask to keep those discussions > > separate as both hypervisor and workload definitions are specific to > > integrator, environment and product (downstream RHV has its own qemu > > with extra patches for example). > > My view on what profiles are for differs from this. In particular > I do *not* consider the profiles to be application specific. The > core rationale for libosinfo existing is to have information that > is shared by all applications managing VMs. Data that is application > specific should be maintained by the application in whatever manner > it wants - application specific data is not in scope for libosinfo. > > I consider profiles to be a way of expressing the best practice > recommendations for configuring a virtual machine to satisfy some > declared scenario. This covers data that is specific to a hypervisor, > or a (guest,hypervisor) pairing, potentially taking into account > goals for runtime performance, as well as other aspects that might > be relevant. A particular application may have particular scenarios > it wants covered by profiles, but that doesn't mean the profiles > are application specific or restricted to only care about "workload", > > 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
