[Libguestfs] Proposed changes for OpenStack

[Richard W.M. Jones]

On Wed, Dec 14, 2011 at 04:03:16PM +0000, Matthew Booth wrote:
> 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?

Yes we could.

On the other hand, mount-local (in guestfish) wouldn't
be very useful without some way to access the event API (whether
that method is using shell scripts or something else).  eg:

  ><fs> mount-local /mnt options:allow_root
  [ guestfish doesn't return to the prompt ]

/mnt isn't usable until some short but undefined time later on.

With the event API bindings it'd look like:

  ><fs> event foo mounted "echo READY"
  ><fs> mount-local /mnt options:allow_root
  [short pause]
  READY

When 'READY' is printed, the mount point is ready to use.

[...]

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

Right; this is a general and well-known limitation of the libguestfs
API -- you mustn't, except in limited situations, call the same handle
from multiple threads.
http://libguestfs.org/guestfs.3.html#multiple_handles_and_multiple_threads

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

No, because umount-local will be a special case.  Essentially it'll
just call 'fusermount -u' so there's no thread safety issues AFAIK.

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

I thought about this too, but now this is pretty ugly too isn't it.
There are two problems (at least) ...

(1) Is the protocol stable enough that we should do this?  I've been
very caution about libguestfs live so far, for exactly this reason.

(2) How do we interleave protocol requests that could be coming from
both guestmount and the library?  For example, where should asynch
events get routed?  The protocol isn't really designed for this unless
there's a "g.give_up_connection()" call.

Actually I think this is pretty ugly compared to adding a mount-local
API.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v