[Libosinfo] RFC: Add clock/timers info in osinfo-db
Martin Sivak
msivak at redhat.com
Tue Jan 22 14:19:26 UTC 2019
Hi,
> I consider profiles to be a way of expressing the best practice
> recommendations for configuring a virtual machine to satisfy some
> declared scenario.
I agree here.
> 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.
But not here. At least not completely. Some configuration is not just
best practice recommendation, but a crucial and (almost-)mandatory
setting that will make the VM work properly regardless of the
scenario. And that kind of information should go into osinfo.
Martin
On Tue, Jan 22, 2019 at 3:08 PM Daniel P. Berrangé <berrange at redhat.com> 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 :|
More information about the Libosinfo
mailing list