From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118324 invoked by alias); 14 Jun 2018 15:16:44 -0000 Mailing-List: contact springfield-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: springfield-owner@sourceware.org Received: (qmail 118035 invoked by uid 89); 14 Jun 2018 15:16:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=evans, Evans, UD:M, wanting X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Subject: Re: Could libguestfs use springfield? To: "Richard W.M. Jones" , =?UTF-8?Q?Vojt=c4=9bch_Trefn=c3=bd?= , libguestfs@redhat.com Cc: springfield@sourceware.org References: <20180614111545.GB14740@redhat.com> <20180614144353.GC14740@redhat.com> From: Steven Whitehouse Message-ID: <4d9bd9d0-00a5-d62a-b13a-eeba9a7c00b6@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180614144353.GC14740@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 14 Jun 2018 15:16:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 14 Jun 2018 15:16:40 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'swhiteho@redhat.com' RCPT:'' X-SW-Source: 2018-06/txt/msg00003.txt.bz2 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=C4=9Bch Trefn=C3=BD 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/afd1c70601c51043684a0245c= e2f63d71a9cc07a/daemon/parted.c#L344 >>> >>> https://github.com/libguestfs/libguestfs/blob/afd1c70601c51043684a0245c= e2f63d71a9cc07a/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=20 what we hope to achieve with Springfield. I'm sure that we'll find that=20 there are a number of projects that we were not initially aware of that=20 might be good areas for collaboration/inspiration as we progress. So=20 that is one reason for the slightly vague description at the moment - I=20 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=20 helpful in explaining what Springfield is all about, so suggestions are=20 very welcome as to how it could be improved. Are there specific parts=20 that are confusing? One reason that there has not yet been the overall unification of=20 subprojects is that this will take time. Initially there are quite a=20 large number of "obvious" gaps in the current tooling, so a lot of the=20 initial work has just been in addressing those gaps. One thing that Paul=20 Evans has been working on, for example, is to ensure that there is good=20 filesystem support for PCP, since that is a good way to get a=20 performance monitoring framework up and running quickly. Jan Tulak started looking at how we might look to provide a unified=20 interface to the various filesystem utilities, however that is a tricky=20 area, since it requires buy-in from the various maintainers of the=20 utilities and there is a bit of chicken-and-egg in relation to wanting=20 something to be useful before adopting it. I'm sure we'll get there in=20 the end, but it will take some time to agree the right approach. Certainly libguestfs sounds like the kind of project that might be=20 useful to integrate with Springfield. One way to help figure that out=20 would be to ask some questions.... =C2=A0- Are there features which libguestfs requires, which have perhaps=20 already been solved in one of the Springfield subprojects? =C2=A0- Are there features which Springfield should have, but which are=20 already solved in libguestfs? So sharing todo lists/requirements would be a good start in looking for=20 common ground. On the technology side, I don't think that there are any hard and fast=20 rules on what we use in Springfield. My own hope is that it will remain=20 modular enough that we can easily change components if required - as=20 with any project, not every decision made at the start will necessarily=20 be optimal, so my feeling is that we should design with that in mind and=20 make it easy to replace/upgrade components in the future, so far as=20 possible. I hope that gives a bit more background, Steve.