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
