From: Steven Whitehouse <swhiteho@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>,
"Vojtěch Trefný" <vtrefny@redhat.com>,
libguestfs@redhat.com
Cc: springfield@sourceware.org
Subject: Re: Could libguestfs use springfield?
Date: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <4d9bd9d0-00a5-d62a-b13a-eeba9a7c00b6@redhat.com> (raw)
In-Reply-To: <20180614144353.GC14740@redhat.com>
Hi,
On 14/06/18 15:43, Richard W.M. Jones wrote:
> [Adding libguestfs mailing list]
>
> On Thu, Jun 14, 2018 at 04:15:57PM +0200, Vojtěch Trefný wrote:
>>
>> On 06/14/2018 01:15 PM, Richard W.M. Jones wrote:
>>> libguestfs provides a C library and large set of tools for
>>> manipulating disk images. http://libguestfs.org/
>>>
>>> As part of this we provide APIs to open VM disks and do things like
>>> enumerate partitions or resize logical volumes. The actual way this
>>> works currently is we run the external commands (eg. parted, lvresize)
>>> inside a small virtual machine and pass the right command line options
>>> or parse the output. In some cases we're also parsing stuff out of
>>> kernel /sys/block.
>>>
>>> We've accumulated a large amount of code to do this (I counted 60619
>>> lines of code in the current version). Here are a few examples so you
>>> can see in concrete terms what I'm talking about:
>>>
>>> https://github.com/libguestfs/libguestfs/blob/afd1c70601c51043684a0245ce2f63d71a9cc07a/daemon/parted.c#L344
>>>
>>> https://github.com/libguestfs/libguestfs/blob/afd1c70601c51043684a0245ce2f63d71a9cc07a/daemon/lvm.c#L271
>>>
>>> Steven W pointed me to "Project Springfield" and it sort of looks like
>>> it's in the same area. Could libguestfs replace the parsing code
>>> above with this?
>>>
>>> What might be problems: We have no python or dbus in the appliance.
>>> So anything that depends on those is a non-starter.
>>>
>>> TBH the project webpage left me more confused than enlightened. There
>>> seem to be lots of projects (subprojects?) doing stuff with odd names
>>> and no unifying philosophy, and I'm not sure if Project Springfield is
>>> a thing or more of an intention.
>>>
>>> Rich.
>>>
>> Hi, project springfield is a collection of existing projects,
>> libblockdev is probably the "subproject" you are looking for. It is
>> a plugin based C library -- we have plugins for working with btrfs,
>> filesystems (ext, xfs, vfat and ntfs), lvm, mdraid, partitions etc.
>> It mostly also uses the command line tools and in some cases also
>> other existing libraries (libcryptsetup, libmount, libparted...).
>>
>> Libblockdev Github repo: https://github.com/storaged-project/libblockdev
>> and API documentation: http://storaged.org/libblockdev/
>>
>> From the code you sent it looks like libblockdev covers most of the
>> functionality libguestfs needs. Some functionality is missing (e.g.
>> we don't support changing of uuid for lvs) but we can add these
>> missing bits.
>>
>> --
>> Vojtech Trefny
If there is scope for cooperation in this area, then that is very much
what we hope to achieve with Springfield. I'm sure that we'll find that
there are a number of projects that we were not initially aware of that
might be good areas for collaboration/inspiration as we progress. So
that is one reason for the slightly vague description at the moment - I
expect this to tighten up a bit as things mature.
That said we do want to make sure that the docs on the web site are
helpful in explaining what Springfield is all about, so suggestions are
very welcome as to how it could be improved. Are there specific parts
that are confusing?
One reason that there has not yet been the overall unification of
subprojects is that this will take time. Initially there are quite a
large number of "obvious" gaps in the current tooling, so a lot of the
initial work has just been in addressing those gaps. One thing that Paul
Evans has been working on, for example, is to ensure that there is good
filesystem support for PCP, since that is a good way to get a
performance monitoring framework up and running quickly.
Jan Tulak started looking at how we might look to provide a unified
interface to the various filesystem utilities, however that is a tricky
area, since it requires buy-in from the various maintainers of the
utilities and there is a bit of chicken-and-egg in relation to wanting
something to be useful before adopting it. I'm sure we'll get there in
the end, but it will take some time to agree the right approach.
Certainly libguestfs sounds like the kind of project that might be
useful to integrate with Springfield. One way to help figure that out
would be to ask some questions....
- Are there features which libguestfs requires, which have perhaps
already been solved in one of the Springfield subprojects?
- Are there features which Springfield should have, but which are
already solved in libguestfs?
So sharing todo lists/requirements would be a good start in looking for
common ground.
On the technology side, I don't think that there are any hard and fast
rules on what we use in Springfield. My own hope is that it will remain
modular enough that we can easily change components if required - as
with any project, not every decision made at the start will necessarily
be optimal, so my feeling is that we should design with that in mind and
make it easy to replace/upgrade components in the future, so far as
possible.
I hope that gives a bit more background,
Steve.
prev parent reply other threads:[~2018-06-14 15:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:00 Richard W.M. Jones
2018-01-01 0:00 ` Vojtěch Trefný
2018-01-01 0:00 ` Richard W.M. Jones
2018-01-01 0:00 ` Steven Whitehouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d9bd9d0-00a5-d62a-b13a-eeba9a7c00b6@redhat.com \
--to=swhiteho@redhat.com \
--cc=libguestfs@redhat.com \
--cc=rjones@redhat.com \
--cc=springfield@sourceware.org \
--cc=vtrefny@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).