Northbound API - Presentation this Friday
Hi all, This Friday (18/May - 8am PST) I'll be making a presentation about my proposal to introduce a YANG-based northbound API in FRR. The main goal of this work is to provide a better interface to configure and monitor FRR programmatically. Everyone is welcomed to attend, no invitations needed. Link of the conference call: https://bluejeans.com/9192742159/ Best Regards, Renato.
Hi all, Links to the presentation slides: https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=0 (preview in the browser) https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=1 (force download) Once again, everyone is welcomed to attend the presentation tomorrow! Cheers, Renato. On Wed, May 16, 2018 at 11:48 PM, Renato Westphal <renato@opensourcerouting.org> wrote:
Hi all,
This Friday (18/May - 8am PST) I'll be making a presentation about my proposal to introduce a YANG-based northbound API in FRR. The main goal of this work is to provide a better interface to configure and monitor FRR programmatically.
Everyone is welcomed to attend, no invitations needed.
Link of the conference call: https://bluejeans.com/9192742159/
Best Regards, Renato.
-- Renato Westphal
Hello Renato, Very nice support. As mention before, unfortunately I could not attend the meeting today, so here it is my remarks and questions: * First I fully support your proposal. I'm very happy to see Yang / Netconf / Restconf sup_p_ort coming for FRR and I'm very impatient to test it * Regarding the amount of work, I'm ready to help (at least for my patches) * Regarding sysrepo or ConfD, I have no particular opinion * Regarding transactional CLI, I think this feature must become the default one with 'commit' command that check the syntax. In addition, when you preform some CLI configuration, it is sometimes preferable to have all the modification apply at once instead of applying step by step, just to avoid bad effect between the different modifications * Concerning the show command, I think that you could collect information through a simple HTTP GET with Restconf. It is working like that in OpenDayLight for example * Last question: do you know if there is some 'yang tools' available with lbyang in order to help us building new CLI / features .i.e. generating automatically structure skeleton ? I'm referring to the OpenDayLight project where you start first by writing a yang model which then produce Java Class automatically through the yang tools provided by OpenDayLight. For example, in FRR, such tools could automatically generate 'C' structure in *.h file for parser and serializer of protocol, CLI ... I wish a nice presentation and will read carefully the minutes. Regards Olivier Le 17/05/2018 à 18:45, Renato Westphal a écrit :
Hi all,
Links to the presentation slides: https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=0 (preview in the browser) https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=1 (force download)
Once again, everyone is welcomed to attend the presentation tomorrow!
Cheers, Renato.
On Wed, May 16, 2018 at 11:48 PM, Renato Westphal <renato@opensourcerouting.org> wrote:
Hi all,
This Friday (18/May - 8am PST) I'll be making a presentation about my proposal to introduce a YANG-based northbound API in FRR. The main goal of this work is to provide a better interface to configure and monitor FRR programmatically.
Everyone is welcomed to attend, no invitations needed.
Link of the conference call: https://bluejeans.com/9192742159/
Best Regards, Renato.
On Fri, May 18, 2018 at 5:06 AM, Olivier Dugeon <olivier.dugeon@orange.com> wrote:
Hello Renato,
Very nice support. As mention before, unfortunately I could not attend the meeting today, so here it is my remarks and questions:
First I fully support your proposal. I'm very happy to see Yang / Netconf / Restconf support coming for FRR and I'm very impatient to test it Regarding the amount of work, I'm ready to help (at least for my patches)
Hi Olivier, Thanks, any help will be welcomed :)
Regarding sysrepo or ConfD, I have no particular opinion Regarding transactional CLI, I think this feature must become the default one with 'commit' command that check the syntax. In addition, when you preform some CLI configuration, it is sometimes preferable to have all the modification apply at once instead of applying step by step, just to avoid bad effect between the different modifications
I agree the transactional CLI should be enabled by default, but only after we convert all configuration commands to the new northbound model. The problem here is that commands not converted to the new northbound model change the running configuration directly. My concern is that things can get confusing if some commands change the candidate configuration and others change the running configuration. Once we convert everything we won't have this problem anymore. When the transaction-based mode is not used, all configuration commands are followed by an implicit "commit" (i.e. one transaction per change).
Concerning the show command, I think that you could collect information through a simple HTTP GET with Restconf. It is working like that in OpenDayLight for example
Fetching the whole configuration using a simple HTTP GET should be possible when using the ConfD northbound plugin. However I can't test this because RESTCONF support isn't available in ConfD Basic (the free version). In the future this might also be possible using the Sysrepo northbound plugin if support for RESTCONF is integrated in Netopeer2.
Last question: do you know if there is some 'yang tools' available with lbyang in order to help us building new CLI / features .i.e. generating automatically structure skeleton ? I'm referring to the OpenDayLight project where you start first by writing a yang model which then produce Java Class automatically through the yang tools provided by OpenDayLight. For example, in FRR, such tools could automatically generate 'C' structure in *.h file for parser and serializer of protocol, CLI ...
Good question. libyang seems to be very minimalistic by design and they don't provide tools like that. But the good news is that we can use libyang to create our own tools very easily. For example, I wrote a tool called 'gen_northbound_callbacks' which takes a YANG module as input and generates skeleton callbacks [1] for this module. This saves a lot of time because the programmer only needs to worry about implementing real code, all the boilerplate will be there already. The possibility to auto-generate code is one of the advantages of using YANG and data modeling languages in general. Thanks for your feedback! [1] https://github.com/opensourcerouting/frr/blob/cb0560ade9/ripd/rip_northbound... -- Renato Westphal
Just a quick update to everyone: I've managed to build libyang on OpenBSD and FreeBSD, and the fixes were trivial. I've also successfully tested libyang on those platforms. We're now getting in touch with the libyang maintainers to discuss how to provide official support and packages for *BSD and OmniOS/Solaris. On Thu, May 17, 2018 at 1:45 PM, Renato Westphal <renato@opensourcerouting.org> wrote:
Hi all,
Links to the presentation slides: https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=0 (preview in the browser) https://www.dropbox.com/s/zhybthruwocbqaw/netdef-frr-northbound.pdf?dl=1 (force download)
Once again, everyone is welcomed to attend the presentation tomorrow!
Cheers, Renato.
On Wed, May 16, 2018 at 11:48 PM, Renato Westphal <renato@opensourcerouting.org> wrote:
Hi all,
This Friday (18/May - 8am PST) I'll be making a presentation about my proposal to introduce a YANG-based northbound API in FRR. The main goal of this work is to provide a better interface to configure and monitor FRR programmatically.
Everyone is welcomed to attend, no invitations needed.
Link of the conference call: https://bluejeans.com/9192742159/
Best Regards, Renato.
-- Renato Westphal
-- Renato Westphal
participants (2)
-
Olivier Dugeon -
Renato Westphal