> IOW there should not be any distinction between the way we deal > with a general purpose profile for a guest OS, from the way we > deal with an SAP or Oracle optimized profile for a guest OS. I > would consider it a big failure if we had different ways to > handle the general purpose config vs the application optimized > config. The issue here is in maintenance. Either you maintain the full matrix of profiles or you have to deal with conflicts between what guest OS, application and hypervisor all allow. Also some of the configuration logic depends on hypervisor, libvirt and kernel and product versions you will not be able to express. Some device might be working according to the database, but the product owners (RHV, CNV, ..) might decide to not use it for support reasons (legal, too many bugs, integration issues..). So the product specific (as opposed to generic) application profile can be based on more than just generally available hard requirements data. What we are after are the pure data right now as we have to prepare custom templates anyway. Neither CNV nor oVirt for example use pure libvirt XML. Both add additional information needed for the whole ecosystem to work properly. Martin On Tue, Jan 22, 2019 at 4:17 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Tue, Jan 22, 2019 at 03:54:17PM +0100, Martin Sivak wrote: > > > So we can > > > have some profiles that are generic best practice for the guest + > > > hypervisor combination. > > > > I probably still do not understand where is the line between osinfo a > > profiles then. What you are talking about (hypervisor + guest OS) > > seems to me to belong to osinfo. > > > > Profiles we asked Martin for (as the primary request was probably > > driven from us at the beginning) were really ment to be used for > > workload specific settings on top or in combination with osinfo > > (io-intensive, SAP HANA, OracleDB, ...). > > Traditionally lots of logic around how to build a libvirt domain XML > to configure a guest according to best practice for a given deployment > scenario was embedded in applications as code. This was always > undesirable since it caused logic duplication across mgmt apps. > > Libosinfo dealt with a small piece of this by allowing optimal > virtual devices to be identified via the DB. > > Long ago there was an abortive attempt to address the more general > problem of writing XML via an set of APIS (libvirt-designer + > libvirt-builder). This failed as a concept for various reasons, not > least that doing it via an API is quite inflexible. > > The logic that apps hardcoded for configuring a guest OS XML was > usually aiming at an design that was "general purpose" good enough > for any workload, but not optimal for every workload. Apps could > have added app specific logic to optimize for SAP, Oracle, etc > but that just makes the existing problem of hardcoded logic even > worse. > > Having a concept of OS profiles in libosinfo is intended to address > the problem of apps all harcoding rules for building XML configs > in the general case. By providing such a feature we could reduce > the amount of harcoded logic in applications, and by extension this > will also make it trivial to provide profiles that are optimized > for specific applications, alongside the general purpose guest > OS profile. > > IOW there should not be any distinction between the way we deal > with a general purpose profile for a guest OS, from the way we > deal with an SAP or Oracle optimized profile for a guest OS. I > would consider it a big failure if we had different ways to > handle the general purpose config vs the application optimized > config. > > 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
