Re: [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

[resending to include OSP devs ]

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Wed, Apr 4, 2018 at 7:23 PM, Yaniv Lavi  wrote:

> [resending to include KubeVirt devs ]
>
> YANIV LAVI
>
> SENIOR TECHNICAL PRODUCT MANAGER
>
> Red Hat Israel Ltd. 
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
> ylavi
>   TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat 
>    Red Hat 
> 
>
>
> On Wed, Apr 4, 2018 at 7:07 PM, Yaniv Lavi  wrote:
>
>> Hi,
>> I'd like to go one step back and discuss why we should try to do this on
>> the high level.
>>
>> For the last 5-10 years of KVM development, we are pragmatically
>> providing the Linux host level APIs via project specific host
>> agents/integration code (Nova agent, oVirt host agent, virt-manager).
>> In recent time we see new projects that have similar requirements
>> (Cockpit, different automation tool, KubeVirt), this means that all of the
>> Linux virt stack consumers are reinventing the wheel and using very
>> different paths to consume the partial solutions that are provided today.
>>
>> The use of the Linux virt stack is well defined by the existing projects
>> scope and it makes a lot of sense to try to provide the common patterns via
>> the virt stack directly as a host level API that different client or
>> management consume.
>> The main goal is to improve the developer experience for virtualization
>> management applications with an API set that is useful to the entire set of
>> tools (OSP, oVirt, KubeVirt, Cockpit and so on).
>>
>> The Linux virt developer community currently is not able to provide best
>> practices and optimizations from single node knowledge. This means that all
>> of that smarts is locked to the specific project integration in the good
>> case or not provided at all and the projects as a whole lose from that.
>> When testing the Linux virt stack itself and since each project has
>> different usage pattern, we lose the ability to test abilities on the lower
>> level making the entire stack less stable and complete for new features.
>>
>> This also limits the different projects ability to contribute back to the
>> Linux stack based on their user and market experience for others in open
>> source to gain.
>>
>> I understand this shift is technically challenging for existing projects,
>> but I do see value in doing this even for new implementation like Cockpit
>> and KubeVirt.
>> I also believe that the end result could be appealing enough to cause
>> project like OSP, virt-manager and oVirt to consider to reduce the existing
>> capabilities of their host side integrations/agents to shims on the host
>> level and reuse the common/better-tested pattern as clients that was
>> developed against the experience of the different projects.
>>
>> I call us all to collaborate and try to converge on a solution that will
>> help all in the long term in the value you get from the common base.
>>
>>
>> Thanks,
>>
>> YANIV LAVI
>>
>> SENIOR TECHNICAL PRODUCT MANAGER
>>
>> Red Hat Israel Ltd. 
>>
>> 34 Jerusalem Road, Building A, 1st floor
>>
>> Ra'anana, Israel 4350109
>>
>> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
>> ylavi
>>   TRIED. TESTED. TRUSTED. 
>> @redhatnews    Red Hat 
>>    Red Hat 
>> 
>>
>>
>> On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
>> wrote:
>>
>>> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
>>> > >
>>> > > > One more thing could be automatically figuring out best values
>>> based on
>>> > > > libosinfo-provided data.
>>> > > >
>>> > > > 2) Policies
>>> > > >
>>> > > > Lot of the time there are parts of the domain definition that need
>>> to be
>>> > > > added, but nobody really cares about them.  Sometimes it's enough
>>> to
>>> > > > have few templates, another time you might want to have a policy
>>> > > > per-scenario and want to combine them in various ways.  For
>>> example with
>>> > > > the data provided by point 1).
>>> > > >
>>> > > > For example if you want PCI-Express, you need the q35 machine
>>> type, but
>>> > > > you don't 

Re: [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

[resending to include KubeVirt devs ]

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Wed, Apr 4, 2018 at 7:07 PM, Yaniv Lavi  wrote:

> Hi,
> I'd like to go one step back and discuss why we should try to do this on
> the high level.
>
> For the last 5-10 years of KVM development, we are pragmatically providing
> the Linux host level APIs via project specific host agents/integration code
> (Nova agent, oVirt host agent, virt-manager).
> In recent time we see new projects that have similar requirements
> (Cockpit, different automation tool, KubeVirt), this means that all of the
> Linux virt stack consumers are reinventing the wheel and using very
> different paths to consume the partial solutions that are provided today.
>
> The use of the Linux virt stack is well defined by the existing projects
> scope and it makes a lot of sense to try to provide the common patterns via
> the virt stack directly as a host level API that different client or
> management consume.
> The main goal is to improve the developer experience for virtualization
> management applications with an API set that is useful to the entire set of
> tools (OSP, oVirt, KubeVirt, Cockpit and so on).
>
> The Linux virt developer community currently is not able to provide best
> practices and optimizations from single node knowledge. This means that all
> of that smarts is locked to the specific project integration in the good
> case or not provided at all and the projects as a whole lose from that.
> When testing the Linux virt stack itself and since each project has
> different usage pattern, we lose the ability to test abilities on the lower
> level making the entire stack less stable and complete for new features.
>
> This also limits the different projects ability to contribute back to the
> Linux stack based on their user and market experience for others in open
> source to gain.
>
> I understand this shift is technically challenging for existing projects,
> but I do see value in doing this even for new implementation like Cockpit
> and KubeVirt.
> I also believe that the end result could be appealing enough to cause
> project like OSP, virt-manager and oVirt to consider to reduce the existing
> capabilities of their host side integrations/agents to shims on the host
> level and reuse the common/better-tested pattern as clients that was
> developed against the experience of the different projects.
>
> I call us all to collaborate and try to converge on a solution that will
> help all in the long term in the value you get from the common base.
>
>
> Thanks,
>
> YANIV LAVI
>
> SENIOR TECHNICAL PRODUCT MANAGER
>
> Red Hat Israel Ltd. 
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
> ylavi
>   TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat 
>    Red Hat 
> 
>
>
> On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
> wrote:
>
>> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
>> > >
>> > > > One more thing could be automatically figuring out best values
>> based on
>> > > > libosinfo-provided data.
>> > > >
>> > > > 2) Policies
>> > > >
>> > > > Lot of the time there are parts of the domain definition that need
>> to be
>> > > > added, but nobody really cares about them.  Sometimes it's enough to
>> > > > have few templates, another time you might want to have a policy
>> > > > per-scenario and want to combine them in various ways.  For example
>> with
>> > > > the data provided by point 1).
>> > > >
>> > > > For example if you want PCI-Express, you need the q35 machine type,
>> but
>> > > > you don't really want to care about the machine type.  Or you want
>> to
>> > > > use SPICE, but you don't want to care about adding QXL.
>> > > >
>> > > > What if some of these policies could be specified once (using some
>> DSL
>> > > > for example), and used by virtuned to merge them in a unified and
>> > > > predictable way?
>> > > >
>> > > > 3) Abstracting the XML
>> > > >
>> > > > This is probably just usable for stateless apps, but it might happen
>> > > > that some apps don't really want to care about the XML at all.  They
>> > > > just want an abstract view of the domain, possibly add/remove a
>> device
>> > > > and that's it.  We could do that as well.  I can't really tell how
>> much
>> > 

Re: [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

Hi,
I'd like to go one step back and discuss why we should try to do this on
the high level.

For the last 5-10 years of KVM development, we are pragmatically providing
the Linux host level APIs via project specific host agents/integration code
(Nova agent, oVirt host agent, virt-manager).
In recent time we see new projects that have similar requirements (Cockpit,
different automation tool, KubeVirt), this means that all of the Linux virt
stack consumers are reinventing the wheel and using very different paths to
consume the partial solutions that are provided today.

The use of the Linux virt stack is well defined by the existing projects
scope and it makes a lot of sense to try to provide the common patterns via
the virt stack directly as a host level API that different client or
management consume.
The main goal is to improve the developer experience for virtualization
management applications with an API set that is useful to the entire set of
tools (OSP, oVirt, KubeVirt, Cockpit and so on).

The Linux virt developer community currently is not able to provide best
practices and optimizations from single node knowledge. This means that all
of that smarts is locked to the specific project integration in the good
case or not provided at all and the projects as a whole lose from that.
When testing the Linux virt stack itself and since each project has
different usage pattern, we lose the ability to test abilities on the lower
level making the entire stack less stable and complete for new features.

This also limits the different projects ability to contribute back to the
Linux stack based on their user and market experience for others in open
source to gain.

I understand this shift is technically challenging for existing projects,
but I do see value in doing this even for new implementation like Cockpit
and KubeVirt.
I also believe that the end result could be appealing enough to cause
project like OSP, virt-manager and oVirt to consider to reduce the existing
capabilities of their host side integrations/agents to shims on the host
level and reuse the common/better-tested pattern as clients that was
developed against the experience of the different projects.

I call us all to collaborate and try to converge on a solution that will
help all in the long term in the value you get from the common base.


Thanks,

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
wrote:

> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
> > >
> > > > One more thing could be automatically figuring out best values based
> on
> > > > libosinfo-provided data.
> > > >
> > > > 2) Policies
> > > >
> > > > Lot of the time there are parts of the domain definition that need
> to be
> > > > added, but nobody really cares about them.  Sometimes it's enough to
> > > > have few templates, another time you might want to have a policy
> > > > per-scenario and want to combine them in various ways.  For example
> with
> > > > the data provided by point 1).
> > > >
> > > > For example if you want PCI-Express, you need the q35 machine type,
> but
> > > > you don't really want to care about the machine type.  Or you want to
> > > > use SPICE, but you don't want to care about adding QXL.
> > > >
> > > > What if some of these policies could be specified once (using some
> DSL
> > > > for example), and used by virtuned to merge them in a unified and
> > > > predictable way?
> > > >
> > > > 3) Abstracting the XML
> > > >
> > > > This is probably just usable for stateless apps, but it might happen
> > > > that some apps don't really want to care about the XML at all.  They
> > > > just want an abstract view of the domain, possibly add/remove a
> device
> > > > and that's it.  We could do that as well.  I can't really tell how
> much
> > > > of a demand there is for it, though.
> > >
> > > It is safe to say that applications do not want to touch XML at all.
> > > Any non-trivial application has created an abstraction around XML,
> > > so that they have an API to express what they want, rather than
> > > manipulating of strings to format/parse XML.
> > >
> >
> > Sure, this was just meant to be a question as to whether it's worth
> > pursuing or not.  You make a good point on why it is not (at least for
> > existing apps).
> >
> > However, since this was optional, the way this would look without the
> > XML abstraction is that both input and output would be valid domain
> > definitions, ultimately resulting in something similar to virt-xml with
> > the added