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

Re: [Libguestfs] Proposed changes for OpenStack



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.

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]