On Thu, Nov 17, 2011 at 11:14 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote: >> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote: >> > >> > >> > ----- Original Message ----- >> > > I have been following this thread pretty closely and the one sentence >> > > summary of the current argument is: ovirt-guest-agent is already >> > > featureful >> > > and tested, so let's drop qemu-ga and have everyone adopt >> > > ovirt-guest-agent. >> > >> > What we're suggesting is let's drop *one* of the two agents (obviously it >> > would be easier for us to drop qemu-ga, but we'd rather reach consensus and >> > unite behind one agent regardless of which agent it is). >> > >> > > Unfortunately, this track strays completely away from the stated goal of >> > > convergence. I have at least two examples of why the greater KVM >> > > community >> > > can never adopt ovirt-guest-agent as-is. To address this, I would like >> > > to >> > > counter with an example on how qemu-ga can enable the deployment of >> > > ovirt-guest-agent features and satisfy the needs of the whole community >> > > at >> > > the same time. >> > > >> > > 1) Scope: The ovirt-guest-agent contains functionality that is >> > > incredibly >> > > useful within the context of oVirt. Single Sign-on is very handy but KVM >> > > users outside the scope of oVirt will not want this extra complexity in >> > > their agent. For simplicity they will probably just write something >> > > small >> > > that does what they need (and we have failed to provide a ubiquitous KVM >> > > agent). >> > >> > I totally agree, but that could easily be resolved using the plugin >> > architecture suggested before. >> > >> > > >> > > 1) Deployment complexity: The more complex the guest agent is, the more >> > > often it will need to be updated (bug/security fixes, distro >> > > compatibility, >> > > new features). Rolling out guest agent updates does not scale well in >> > > large >> > > environments (especially when the guest and host administrators are not >> > > the >> > > same person). >> > >> > Using plugins, you just deploy the ones you need, keeping the attack >> > surface / >> > #bugs / need to update lower >> >> In order for any KVM guest agent to become ubiquitous, I think the code >> _must_ live >> in the qemu repository. This includes the base infrastructure and a core >> set of >> plugins to provide the current set of qemu-ga APIs. This way, both endpoints >> (host/guest) can evolve together. How easy would it be to extract this basic >> infrastructure from the ovirt-guest-agent? Is the qemu project opposed to a >> Python agent? > > IMHO Python would be a really bad choice for the agent. An agent wants to be > maximally portable to any guest OS, regardless of its vintage. The changes > between each python release, even within the 2.x stream, let alone between > 2.x and 3.x would cause us endless compatibility problems upon deployment. > And while python is common on Linux, we don't really want to get into the > business of installing the python runtime on Windows or other OS, simply to > run an agent. > > Regards, > Daniel > --
I agree with Daniel, A good example to get inspired from is the ZABBIX agent. A single C source tree that can be compiled to many Unix and Windows binaries. Eric Gaulin ___
