From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RU1YU-0002Lq-8A for qemu-devel@nongnu.org; Fri, 25 Nov 2011 14:35:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RU1YS-0004do-O0 for qemu-devel@nongnu.org; Fri, 25 Nov 2011 14:35:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RU1YS-0004dd-Gj for qemu-devel@nongnu.org; Fri, 25 Nov 2011 14:35:24 -0500 Message-ID: <4ECFED9F.7@redhat.com> Date: Fri, 25 Nov 2011 21:33:51 +0200 From: Barak Azulay MIME-Version: 1.0 References: <20111116202451.GI2726@us.ibm.com> <78db1bdf-6440-4808-9658-19fe0e7043ea@zmail07.collab.prod.int.phx2.redhat.com> <20111117155833.GN2726@us.ibm.com> <20111117161442.GF16420@redhat.com> In-Reply-To: <20111117161442.GF16420@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Gal Hammer , qemu-devel@nongnu.org, vdsm-devel@lists.fedorahosted.org, Ayal Baron , Adam Litke , arch@ovirt.org On 11/17/2011 06:14 PM, Daniel P. Berrange 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. And still the ovirt-guest-agent: - is written in python - Supports many guest OSs (f15, f16, RHEL6.X RHEL5.X, winXP, W7 (32&64), 2k3 (32/64) 2k8 (32/64/R2)) - Deployed in binary format on win (py2exe ... no need to install python and no compatibility problems) > > Regards, > Daniel