From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:50728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752899AbdK0QYl (ORCPT ); Mon, 27 Nov 2017 11:24:41 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DBF5BC049D4C for ; Mon, 27 Nov 2017 16:24:41 +0000 (UTC) Subject: Re: [proposal] making filesystem tools more machine friendly To: Jan Tulak Cc: linux-fsdevel@vger.kernel.org References: <095aeded-39d1-c331-22cc-cdf1da069e3f@redhat.com> From: Andrew Price Message-ID: <75aa3bae-76a6-ff48-e33c-cd0f27d13231@redhat.com> Date: Mon, 27 Nov 2017 16:24:40 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 27/11/17 15:38, Jan Tulak wrote: > On Mon, Nov 27, 2017 at 3:57 PM, Andrew Price wrote: >> On 30/06/17 09:17, Jan Tulak wrote: >>> >>> AKA filesystem API >>> >>> Hi guys >>> >>> Currently, filesystem tools are not made with automation in mind. So >>> any tool that wants to interact with filesystems (be it for >>> automation, or to provide a more user-friendly interface) has to >>> screen scrape everything and cope with changing outputs. >>> >>> I think it is the time to focus some thoughts on how to make the fs >>> tools easier to be used by scripts and other tools. >> >> >> What's the status of this? I'd like to make sure gfs2-utils is geared up for >> it and catered for, whatever solution is chosen. > > I decided to go the way of using wrapper at first - that solves some > of the use cases I'm concerned sooner. And if there are enough users > of this wrapper, then in a time I can look at the integration again. > >> >> Perhaps this ship has already sailed, but, I think a json dependency may be >> a little too heavy, and perhaps a simpler stream of key-value lists that can >> be generated with fprintf() would suffice? For accepting options, we already >> have code to parse that sort of thing as we handle "foo=bar,baz=42" style > > That's not enough once you have any hierarchy in your data, i.e. > multiple volumes in a group, and each has a name or path... Hence, I > strived for an advanced format, like JSON. A nested format is not necessarily required to describe a nested structure. It does take away the need for a "parent" field in each record but I'm not convinced that is a sufficent trade-off for adding a json lib dependency. > However, if gfs2-utils does > not need anything more, there is no need to use a complex solution for > this moment. I think the only hierarchical support we might want is for progress reporting to be split into stages and sub-stages. > What makes it easy to add a common format, later on, is not having > prints all through the program together with a heap of exit() calls, I'm not sure I understand this point... > and rather, if there is some structure containing the state from which > the output is created at one point no matter what. Of course, that can > be difficult to achieve if you want to print some progress or if the > program would require deeper changes... which is why I let it be for > now until I can show that there really is a sufficient interest from > the users of a wrapper, and the effort is better justified. Okay, thanks for the update. In case it helps in future, I'm willing to experiment with a (test?) tool that works with the gfs2-utils in a development branch. Andy