[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] Proposed changes for OpenStack

On 12/14/2011 03:13 PM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
I still don't see why we need the guestfish event callbacks.

because ...

The guestfish change is only for us to do testing.

Can't the test be written in another language?


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).

I haven't written any code yet so I don't know for certain that it
will work.  With that in mind, the architecture is as follows:

guestfs_mount_local doesn't return until the filesystem is unmounted.

The thread running guestfs_mount_local is the one which is processing
FUSE requests.  In nuts and bolts terms, guestfs_mount_local calls
fuse_main with certain flags to stop it from forking into the
background (or more likely it'll call some of the lower level libfuse
APIs that fuse_main calls).  No event loop integration is needed.

I just read your original python a little more closely:

 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 ()

The problem with this is that if the event callback does anything to the newly mounted filesystem without a new thread, it'll deadlock. And even if you require this, you're opening a can of worms because you'll then have to make the API threadsafe so you can call g.umount_local() from the thread.

And please don't forget that I'm also opposed to this in principal, as mounting filesystems on the host is not the business of the guestfs API.

How about this instead:


  guestmount -c /path/to/existing/unix/sock /tmp/dir
  ... manipulate /tmp/dir ...
  umount /tmp/dir


If you wanted to remove the requirement to exec guestmount, you could solve that in *guestmount* by exposing it as a library.

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]