Re: [libvirt] Yet another RFC for CAT

> > > > We didn't want to exec external python programs because that certainly > *does* have bad scalability, terrible error reporting facilities and > need to parse ill defined data formats from stdout, etc. It doesn't > magically solve the complexity, just moves it elsewhere where we have > less

Re: [libvirt] Yet another RFC for CAT

On Tue, Sep 12, 2017 at 11:33:53AM +0200, Martin Kletzander wrote: > On Thu, Sep 07, 2017 at 11:02:21AM +0800, 乔立勇(Eli Qiao) wrote: > > > I'm concerned about the idea of not checking 'from' for collisions, > > > if there's allowed a mix of guests with & within 'from'. > > > > eg consider > > > >

Re: [libvirt] Yet another RFC for CAT

On Thu, Sep 07, 2017 at 11:02:21AM +0800, 乔立勇(Eli Qiao) wrote: 2017-09-04 23:57 GMT+08:00 Daniel P. Berrange : On Mon, Sep 04, 2017 at 04:14:00PM +0200, Martin Kletzander wrote: > * The current design (finally something libvirt-related, right?) > > The discussion ended

Re: [libvirt] Yet another RFC for CAT

2017-09-04 23:57 GMT+08:00 Daniel P. Berrange : > On Mon, Sep 04, 2017 at 04:14:00PM +0200, Martin Kletzander wrote: > > * The current design (finally something libvirt-related, right?) > > > > The discussion ended with a conclusion of the following (with my best > >

Re: [libvirt] Yet another RFC for CAT

On Mon, Sep 04, 2017 at 04:14:00PM +0200, Martin Kletzander wrote: > * The current design (finally something libvirt-related, right?) > > The discussion ended with a conclusion of the following (with my best > knowledge, there were so many discussions about so many things that I > would spend too

[libvirt] Yet another RFC for CAT

Hello everyone. Last couple of weeks [1] I was working on CAT for libvirt. Only clean-ups and minor things were pushed into upstream, but as I'm getting closer and closer to actual functionality I'm seeing a problem with our current (already discussed and approved) design. And I would like to