[Libguestfs] Proposed changes for OpenStack

[Matthew Booth]

On 12/14/2011 12:06 PM, Richard W.M. Jones wrote:
> On Wed, Dec 14, 2011 at 11:06:24AM +0000, Matthew Booth wrote:
>> 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.

I still don't see why we need the guestfish event callbacks.

>
> Let me explain this again ...
>
> The guestfish change is only for us to do testing.  OpenStack is
> written in Python and uses the libguestfs-python API.
>
> What Padraig's current patch is doing is essentially assembling the
> command line for guestmount and calling out to it.  This is
> reminiscent of the bad old days when inspection was part of a separate
> set of Perl tools, and we had to coordinate between virt-inspector and
> guestfish by assembling command lines.
>
> This would work much better if Padraig was able to do:
>
>   g = guestfs.GuestFS ()
>   g.add_drive_opts (...)
>   g.launch ()
>
>   # Locate the filesystems:
>   try:
>     roots = g.inspect_os ()
>     # mount some stuff
>   except:
>     # Inspection failed, backup method:
>     g.list_filesystems ()
>     # mount some stuff
>
>   g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
>   g.mount_local ("/tmp/dir")
>   # In the event callback, start a thread which:
>   # - injects files
>   # - modifies network config
>   # - finally calls g.umount_local ()
>
>   # Finally, tune the filesystem
>   g.tune2fs (...)
>
> You can see this is much cleaner, as well as more efficient, than
> constructing command lines and shelling out to guestmount.

This is an extension of the libguestfs api in a direction which is best 
served by a different tool. I've failed to convince you of this argument 
several times before though, so I'll try a different tack ;)

The reason this isn't going to work is that a FUSE filesystem requires a 
process to exist which can respond to filesystem events as they occur. 
This means that you would have to additionally add functions for 
managing FUSE events, at the very least calling the event handler. The 
API user would have to integrate these calls into their event loop. If 
they didn't have an event loop, they'd have to create one. This isn't 
the simplicity you're looking for.

Alternatively, they could fork. The problem is, if you do that you 
either need to create a separate appliance (the performance overhead 
you're trying to avoid), or create an interface to an existing appliance 
over which commands from multiple sources can be serialised (my suggestion).

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