Re: [proposal] making filesystem tools more machine friendly

[Andrew Price <anprice@redhat.com>]

On 27/11/17 15:38, Jan Tulak wrote:
> On Mon, Nov 27, 2017 at 3:57 PM, Andrew Price <anprice@redhat.com> 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