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:
g.launch()
g.mount(...)
g.foo()
g.bar()
shell("
guestmount -c /path/to/existing/unix/sock /tmp/dir
... manipulate /tmp/dir ...
umount /tmp/dir
")
g.close()
If you wanted to remove the requirement to exec guestmount, you could
solve that in *guestmount* by exposing it as a library.
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