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

Re: [Libguestfs] Proposed changes for OpenStack



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


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