Re: [proposal] making filesystem tools more machine friendly

[Jan Tulak <jtulak@redhat.com>]

On Mon, Nov 27, 2017 at 5:24 PM, Andrew Price <anprice@redhat.com> wrote:
> 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.

json was presented as an option, that is already established and well
known. I'm not against using another format if it is universal enough
and easy to use by 3rd parties, but the discussion never got so far,
because the more important and underlying issues weren't sufficiently
solved. The output format is really just a cosmetical thing.


>
>> 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...

I mean this: Is any failure propagated up to main(), which contains
the only exit() in the whole program, or is exit() called immediately
on any issue, even in functions ten levels of stack deep, without
returning up the stack? If the first, then it is easy to just print
the state of the application at the end of any run, no matter what
happens. If the later, it can more difficult.

>
>> 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.
>

OK, thanks.

Jan