[Libosinfo] RFC: Add clock/timers info in osinfo-db

Martin Sivak msivak at redhat.com
Tue Jan 22 14:16:26 UTC 2019


> 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 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