[Libguestfs] Proposed changes for OpenStack

[Matthew Booth]

On 12/14/2011 10:36 AM, Richard W.M. Jones wrote:
> On Wed, Dec 14, 2011 at 09:33:35AM +0000, Matthew Booth wrote:
>> On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
>>> [These two patches are for discussion only]
>>>
>>> Allow FUSE support to be used directly through the API.
>>> This is the second commit.
>>>
>>> In order to make this usable from guestfish, we have to
>>> also bind the events API in guestfish.  This is the first
>>> commit.
>>
>> There's not really enough information here to evaluate the proposed
>> changes. Can you give an example of what you're trying to do?
>
> There's a very specific need for this in OpenStack.  We want to be
> able to inject files and make other filesystem changes -- and there is
> already common code which assumes the guest filesystem is mounted
> somewhere.  But also we want to call libguestfs APIs such as
> guestfs_tune2fs.  Currently we can do the mounting bit by calling
> guestmount, and we can do the other libguestfs API calls, but we need
> to launch libguestfs twice to do this.
>
> Here is Padraig's current OpenStack patch:
>
> https://review.openstack.org/#change,1993
> https://review.openstack.org/#change,1994

Ok, it's an efficiency thing. However, I still think it's the wrong 
solution. What you really want to do is use 1 appliance for 2 things. We 
already have a mechanism to do that: ATTACH_METHOD_UNIX. Why not update 
guestmount to use it?

>> In general, though, this feels wrong for a couple of reasons.
>> Firstly, a callback mechanism implemented with shell scripts is
>> simply hideous. Imagine trying to use that from another language.
>
> This is only for guestfish (which is a shell script tool).  How would
> you want to capture events in guestfish?

Not quite so hideous, but I remain unconvinced. Use another language? 
That's not a flippant suggestion, btw. There comes a point in shell 
scripting when you're exceeding what it was designed for.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490