Hi,
Behaviour for certain actions needs discussion and the behaviour crosses over
with the work on bgpctl. A command such as bgpctl -j log brief currently
results in a return such as:
“
Logging request sent.
{
}
"
I think this behaviour would be common to anything which effectively does a
fire and forget. We could either remove the json output by doing something
like (but not!):
if(!done) {
//output head
//output tail
}
This would stop a json response altogether. Alternatively we could update
the code to return something like:
“{ response: “Logging request sent” }
Finally we could just error if you call one of those methods with a -j flag?
Just hit the same pattern/issue on ospfctl, so looking to source some
direction. Using openbsd, there has always felt like lots of synergy
between cli interfaces, so just hoping to help continue that :)
Cheers
Richard
> On 11 May 2020, at 13:52, Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
>
> On Mon, May 11, 2020 at 12:38:38PM +0100, Richard Chivers wrote:
>> Hi,
>>
>> I have done some work over the last few days to implement json support
>> into ospfctl following the work done recently in bgpctl.
>>
>> I have some queries, hoping to get some help with.
>>
>> The change involves a refactor of ospfctl, but reuses the recent
>> json.c written by Claudio, that is in the
>> usr.sbin/bgpctl directory. At present no changes have been required at all.
>> What is the best approach here, should/could this be centralised somewhere?
>
> At the moment just copy the files into ospfctl. We did the same thing with
> other bits in the tree. My json API is super minimal and is for sure not
> something that should be put into a common framework right now. The way
> objects and arrays are opened and closed is a bit rough and does not
> always work well.
>
>> In some cases there is room for change, for example ospfctl sh rib &
>> ospfctl sh rib detail.
>>
>> In my view here, it makes sense to have a full list returned rather
>> than splitting json into multiple lists of Router, Network and
>> External.
>> I looked for inspiration in the bgpctl, but couldn't find a similar
>> pattern. The reason for a single list is that if consuming the json,
>> I expect you will not want code that has to iterate over three
>> separate arrays. Just looking for some feedback really. The original
>> split
>> made sense for screen use, just not so sure about machine readability.
>> This issue also applies to ospfctl sh data, which returns 3 lists.
>
> A lot of this is depending on the imsgs used between ospfctl and ospfd.
> IIRC ospfd sends all data in one batch so the multiple lists just happen
> by ospfctl and indeed for json output it would be best to display the rib
> as a single array of entries (which have a similar structure but probably
> per LSA specific attributes).
>
>> When I am finished, should I just post the diff on here? Just
>> conscious it is quite a big refactor, albeit much of the code is
>> reused just moved into output.c as
>> was done for bgpctl.
>
> Please split it up like I did it for bgpctl. I first did a lot of the
> moving and cleanup and only later added the new input mode. This makes the
> individual steps smaller to review.
>
>> I am testing each call individually against a set of openbsd 6.6 boxes
>> we have running, which is great for ospfd. What is the normal
>> practise for ospf6, is there a script run to replicate code changes or
>> is it just a case of making very similar changes line by line?
>
> There is no script, you do it by hand it is quicker.
>
>> Just looking for the general thinking and approach I guess. I don't
>> currently have ospf6 set-up so that would be some overhead.
>> Happy to configure it though if needed/expected.
>
> Get ospfctl first, after that ospf6ctl can be done (and maybe somebody
> else will take care of that).
>
>> Finally what was the driver under bgpctl for the json output, ours is
>> for reading metrics to populate telemetry, just interested as the
>> purpose other
>> people have. Having this context will help in micro decisions when
>> implementing the json structure.
>
> I'm doing this work to provide JSON payloads to external looking glasses.
> I would not put the RIB into telemetry (that is just useless churn and
> load on the telemetry system). In bgpctl the terse outputs are simple
> space separated outputs for telemetry scripting but I guess people will
> also use the JSON output for this.
>
>> As a final thought is this something that is actually wanted
>> generally, I assumed it was as bgpctl has gone/is going in that
>> direction, but just don't want to assume.
>
> I see no reason why not. At least I wont veto it.
>
> --
> :wq Claudio
