staticd: yang definition #5460

vishaldhingra · 2019-12-03T14:03:12Z

Yang files for staticd to use northbound APIs

Co-authored-by: Santosh P K sapk@vmware.com
Co-authored-by: vishaldhingra vdhingra@vmware.com
Signed-off-by: vishaldhingra vdhingra@vmware.com

Spantik · 2019-12-03T14:09:19Z

This is work in progress for staticd migration to northbound and we have used IETF defined data model as much as possible. We are still adding VRF support by mounting network-instance module. Below is the schema tree for the same.

satheeshkarra · 2019-12-03T14:27:17Z

Thanks Vishal for starting this, I am also started working on this.

what i defined was..(based on Internal FRR Implementation)

module: frr-staticd
  +--rw staticd
     +--rw ipv4
     |  +--rw route* [ip-address]
     |  |  +--rw ip-address     ietf-inet-types:ipv4-address
     |  |  +--rw (nexthop)?
     |  |  |  +--:(gateway)
     |  |  |  |  +--rw gateway
     |  |  |  |     +--rw address?   ietf-inet-types:ipv4-prefix
     |  |  |  |     +--rw ifname?    string
     |  |  |  |     +--rw onlink?    boolean
     |  |  |  +--:(ifname)
     |  |  |  |  +--rw ifname?   string
     |  |  |  +--:(Null0)
     |  |  |  |  +--rw Null0?   boolean <false>
     |  |  |  +--:(reject)
     |  |  |  |  +--rw reject?   boolean <false>
     |  |  |  +--:(blackhole)
     |  |  |     +--rw blackhole?   boolean <false>
     |  |  +--rw tag?           uint32
     |  |  +--rw distance?      uint8
     |  |  +--rw vrf?           string
     |  |  +--rw label?         string
     |  |  +--rw nexthop-vrf?   string
     |  +--rw vrf* [vrf]
     |     +--rw vrf      string
     |     +--rw route* [ip-address]
     |        +--rw ip-address     ietf-inet-types:ipv4-address
     |        +--rw (nexthop)?
     |        |  +--:(gateway)
     |        |  |  +--rw gateway
     |        |  |     +--rw address?   ietf-inet-types:ipv4-prefix
     |        |  |     +--rw ifname?    string
     |        |  |     +--rw onlink?    boolean
     |        |  +--:(ifname)
     |        |  |  +--rw ifname?   string
     |        |  +--:(Null0)
     |        |  |  +--rw Null0?   boolean <false>
     |        |  +--:(reject)
     |        |  |  +--rw reject?   boolean <false>
     |        |  +--:(blackhole)
     |        |     +--rw blackhole?   boolean <false>
     |        +--rw tag?           uint32
     |        +--rw distance?      uint8
     |        +--rw label?         string
     |        +--rw nexthop-vrf?   string
     +--rw ipv6
        +--rw route* [ipv6-address]
        |  +--rw ipv6-address    ietf-inet-types:ipv6-address
        |  +--rw (nexthop)?
        |  |  +--:(gateway)
        |  |  |  +--rw gateway
        |  |  |     +--rw address?   ietf-inet-types:ipv6-prefix
        |  |  |     +--rw ifname?    string
        |  |  |     +--rw onlink?    boolean
        |  |  +--:(ifname)
        |  |  |  +--rw ifname?   string
        |  |  +--:(Null0)
        |  |  |  +--rw Null0?   boolean <false>
        |  |  +--:(reject)
        |  |  |  +--rw reject?   boolean <false>
        |  |  +--:(blackhole)
        |  |     +--rw blackhole?   boolean <false>
        |  +--rw tag?            uint32
        |  +--rw distance?       uint8
        |  +--rw vrf?            string
        |  +--rw label?          string
        |  +--rw nexthop-vrf?    string
        +--rw vrf* [vrf]
           +--rw vrf      string
           +--rw route* [ipv6-address]
              +--rw ipv6-address    ietf-inet-types:ipv6-address
              +--rw (nexthop)?
              |  +--:(gateway)
              |  |  +--rw gateway
              |  |     +--rw address?   ietf-inet-types:ipv6-prefix
              |  |     +--rw ifname?    string
              |  |     +--rw onlink?    boolean
              |  +--:(ifname)
              |  |  +--rw ifname?   string
              |  +--:(Null0)
              |  |  +--rw Null0?   boolean <false>
              |  +--:(reject)
              |  |  +--rw reject?   boolean <false>
              |  +--:(blackhole)
              |     +--rw blackhole?   boolean <false>
              +--rw tag?            uint32
              +--rw distance?       uint8
              +--rw label?          string
              +--rw nexthop-vrf?    string

Spantik · 2019-12-03T14:49:25Z

@satheeshkarra most of the internal FRR implimeantion can be handled with Yang data model defined by IETF we added more on to that so that all the commands are taken care.

satheeshkarra · 2019-12-03T14:56:10Z

does above model takes care of negative cases also, some of the options (like, on-link) are available only in certain cases. is the plan to validate them in the callbacks..?

from above it looks like parser doesn't restrict on-link for other NH types.

Spantik · 2019-12-03T15:04:42Z

does above model takes care of negative cases also, some of the options (like, on-link) are available only in certain cases. is the plan to validate them in the callbacks..?

from above it looks like parser doesn't restrict on-link for other NH types.

We can either do this with choice in data model or in validation. We are planning to do that in validation.

satheeshkarra · 2019-12-03T15:09:53Z

If possible can you please restrict this in data model, because our Idea it to only validate Operational data in the call backs, configuration restrictions can be easily validate in the model.

Spantik · 2019-12-03T15:34:57Z

If possible can you please restrict this in data model, because our Idea it to only validate Operational data in the call backs, configuration restrictions can be easily validate in the model.

Sure. We should be able to do it.

NetDEF-CI · 2019-12-03T16:32:18Z

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9924/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

CLANG Static Analyzer Summary

Github Pull Request 5460, comparing to Git base SHA a5f271c

No Changes in Static Analysis warnings compared to base

1 Static Analyzer issues remaining.

See details at
https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9924/artifact/shared/static_analysis/index.html

satheeshkarra

Please take care of Negative cases also

vishaldhingra · 2019-12-04T12:23:53Z

At present libyang has no support for Schema mount.
There is issue raised in libyang for the same : 691

So, we have modified the ietf models to support the VRF.
Once libyang has the support for Schema mount; then we can quickly revert the ietf models to original one.

vishaldhingra · 2019-12-04T12:58:13Z

print frr-routing
module: frr-routing
+--rw routing
+--rw control-plane-protocols
+--rw control-plane-protocol* [type name vrf]
+--rw type identityref
+--rw name string
+--rw vrf frr-vrf:vrf-ref
+--rw frr-staticd:staticd
+--rw frr-staticd:address-family* [address-family]
+--rw frr-staticd:address-family identityref
+--rw frr-staticd:ipv4-route* [destination-prefix]
| +--rw frr-staticd:destination-prefix ietf-inet-types:ipv4-prefix
| +--rw frr-staticd:frr-staticd-next-hop
| +--rw frr-staticd:nexthop-list* [nexthop]
| +--rw frr-staticd:nexthop frr-nexthop:frr-nexthop-ref
+--rw frr-staticd:ipv6-route* [destination-prefix]
+--rw frr-staticd:destination-prefix ietf-inet-types:ipv6-prefix
+--rw frr-staticd:frr-staticd-next-hop
+--rw frr-staticd:nexthop-list* [nexthop]
+--rw frr-staticd:nexthop frr-nexthop:frr-nexthop-ref

satheeshkarra · 2019-12-04T13:19:20Z

rw frr-staticd:table-id? & rw frr-staticd:nexthop-vrf? both will be same right..?

do we need both...?
better proceed with nexthop-vrf, instead of table-id..?, mapping can happen in the backend.

qlyoung

Some initial review comments. I didn't spend time on the IETF models this round.

qlyoung · 2019-12-04T16:32:24Z

yang/frr-staticd.yang

+      case ifname {
+        leaf outgoing-interface {
+          type string {
+            length "1..16";


Any reason this shouldn't be an interface leafref?

qlyoung · 2019-12-04T16:32:43Z

yang/frr-staticd.yang

+      case  gateway {
+        leaf gw-interface {
+          type string {
+            length "1..16";


Any reason this shouldn't be an interface leafref?

qlyoung · 2019-12-04T16:33:08Z

yang/frr-staticd.yang

+          description
+            "Name of the outgoing interface.";
+        }
+        leaf is-onlink {


IMO this should be named onlink and the type should be boolean. I was also of the impression that "onlink" doesn't specify a nexthop so much as it's an attribute of a nexthop. It doesn't mean anything to say "the nexthop for prefix is onlink" where onlink is a noun (as it is here) and not an adjective.

qlyoung · 2019-12-04T16:37:31Z

yang/frr-staticd.yang

+      case Null0 {
+        leaf Null0 {
+          type boolean;
+	  default false;


Please remember to use yanglint to format the models

qlyoung · 2019-12-04T16:38:44Z

yang/frr-staticd.yang

+        }
+      }
+      case Null0 {
+        leaf Null0 {


This is a bit of a special case, since Null0 is treated as a "special" interface name. IMO this doesn't need to be represented in the model at all, it's really an anachronism from other vendors, and it's essentially an alias for the blackhole attribute.

qlyoung · 2019-12-04T16:46:30Z

yang/frr-staticd.yang

+  {
+    description
+      "Augment static route configuration 'next-hop-list'.";
+    uses frr-staticd-nexthop;


I feel like this is the wrong way to go about it. We should have a list of nexthops modeled in one place and then other places that need to reference a nexthop can use a leafref. Thoughts?

@qlyoung thanks for review. I think we need to go over call and discuss this? We wanted to keep it as close to IETF as possible keeping extensions in mind if we have to use leafref then we may not be able to use IETF defined model. Though many things in IETF defined yang model are not being used today and we will be using deviate and delete statements. I think if we can go over call and converge faster on the same.

Sounds good

qlyoung · 2019-12-04T16:46:43Z

yang/frr-staticd.yang

+  {
+    description
+      "Augment static route configuration 'next-hop-list'.";
+    uses frr-staticd-nexthop;


Ditto previous comment regarding leafrefs.

qlyoung · 2019-12-04T16:47:15Z

yang/frr-vrf.yang

+        "vrf name.";
+      leaf name {
+        type string {
+          length "1..36";


1..16, no? And I believe the name of a vrf should be its own type encapsulating this constraint.

done
I have raised the new PR for common yang modules.
Please refer to this PR.
#5525

qlyoung · 2019-12-04T16:47:59Z

yang/ietf/ietf-interfaces@2018-02-20.yang

+    }
+    description
+      "This type is used by data models that need to reference
+       interfaces.";


This is definitely a dup of what exists in the frr-interface module.

@qlyoung thanks for review. I think again we need to go over call and discussion do we need to use frr-interface or use IETF-data model with deviation.

qlyoung · 2019-12-04T16:48:43Z

yang/ietf/ietf-interfaces@2018-02-20.yang

@@ -0,0 +1,1123 @@
+module ietf-interfaces {


We need to decide whether we should augment this module with FRR specific information, or vice versa. In any case this module duplicates the existing frr-interface module and that needs to be resolved.

rwestphal · 2019-12-07T01:38:07Z

Preliminary review: this PR is including modified versions of IETF modules to our tree. We shouldn't do that with any published YANG module since it can easily lead to confusion (e.g. a module named ietf-routing@2018-03-13.yang should be the same regardless of where it was obtained). Modules should only be modified by other modules using either augmentations or deviations. This has the nice side effect of making the differences between the original and modified modules easier to identify.

In any case, the idea for now is to reuse as much as possible from the IETF modules by borrowing nodes from them into our native modules instead of implementing the IETF modules directly (this is documented here). Ideally we would implement the IETF data hierarchy directly in FRR, but that would make things much more difficult so it's probably something that can be left for a second moment. I'm open to discuss this decision in the next weekly meeting.

Note: we already have a couple of IETF modules in our tree but they are there only because they provide useful YANG types like route-distinguisher. They are not being implemented in any way.

qlyoung · 2019-12-07T04:44:28Z

I fully agree with Renato. Reuse published models where sensible and appropriate, but the goal should be to produce a model tailored for FRR, not necessarily one as as close as possible to the standards.

…

On Fri, Dec 6, 2019, 8:38 PM Renato Westphal ***@***.***> wrote: Preliminary review: this PR is including modified versions of IETF modules to our tree. We shouldn't do that with any published YANG module since it can easily lead to confusion (e.g. a module named ***@***.*** should be the same regardless of where it was obtained). Modules should only be modified by other modules using either augmentations or deviations. This has the nice side effect of making the differences between the original and modified modules easier to identify. In any case, the idea for now is to reuse as much as possible from the IETF modules by borrowing nodes from them into our native modules instead of implementing the IETF modules directly (this is documented here <https://github.com/opensourcerouting/frr/wiki/Architecture#yang-models>). Ideally we would implement the IETF data hierarchy directly in FRR, but that would make things much more difficult so it's probably something that can be left for a second moment. I'm open to discuss this decision in the next weekly meeting. Note: we already have a couple of IETF modules in our tree but they are there only because they provide useful YANG types like route-distinguisher. They are not being implemented in any way. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5460?email_source=notifications&email_token=ABUCX6Z2E3BACJQJ6KZDLMLQXL5ABA5CNFSM4JUYRF72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGF2TOA#issuecomment-562801080>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUCX63UA3CXDT7LIW7WAR3QXL5ABANCNFSM4JUYRF7Q> .

Spantik · 2019-12-09T06:03:41Z

Preliminary review: this PR is including modified versions of IETF modules to our tree. We shouldn't do that with any published YANG module since it can easily lead to confusion (e.g. a module named ietf-routing@2018-03-13.yang should be the same regardless of where it was obtained). Modules should only be modified by other modules using either augmentations or deviations. This has the nice side effect of making the differences between the original and modified modules easier to identify.

In any case, the idea for now is to reuse as much as possible from the IETF modules by borrowing nodes from them into our native modules instead of implementing the IETF modules directly (this is documented here). Ideally we would implement the IETF data hierarchy directly in FRR, but that would make things much more difficult so it's probably something that can be left for a second moment. I'm open to discuss this decision in the next weekly meeting.

Note: we already have a couple of IETF modules in our tree but they are there only because they provide useful YANG types like route-distinguisher. They are not being implemented in any way.

Renato - Thanks a lot for your review. I agree with you. While initially we did remove from IETF module then we used deviation and delete which worked well. We will resubmit our patch again which will take care of your comments.

polychaeta

Thanks for your contribution to FRR!

One of your commits has a missing or badly formatted Signed-off-by line; we can't accept your contribution until all of your commits have one

If you are a new contributor to FRR, please see our contributing guidelines.

polychaeta

Thanks for your contribution to FRR!

One of your commits has a missing or badly formatted Signed-off-by line; we can't accept your contribution until all of your commits have one

If you are a new contributor to FRR, please see our contributing guidelines.

polychaeta

Thanks for your contribution to FRR!

One of your commits has a missing or badly formatted Signed-off-by line; we can't accept your contribution until all of your commits have one

If you are a new contributor to FRR, please see our contributing guidelines.

NetDEF-CI · 2019-12-20T06:28:22Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10171/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

FreeBSD 11 amd64 build: Failed (click for details)

Make failed for FreeBSD 11 amd64 build:
(see full Make log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10171/artifact/CI009BUILD/ErrorLog/log_make.txt)

  CC       lib/json.lo
  CC       lib/keychain.lo
  CC       lib/lib_errors.lo
  CC       lib/libfrr.lo
  CC       lib/linklist.lo
  CC       lib/log.lo
  CLIPPY   lib/log_vty_clippy.c
  CC       lib/log_vty.lo
  CC       lib/md5.lo

FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10171/artifact/CI009BUILD/config.status/config.status

Successful on other platforms

Fedora 29 amd64 build
Debian 10 amd64 build
OpenBSD 6 amd64 build
NetBSD 6 amd64 build
CentOS 7 amd64 build
Ubuntu 18.04 amd64 build
FreeBSD 12 amd64 build
Ubuntu 18.04 ppc64le build
Debian 9 amd64 build
Ubuntu 16.04 i386 build
NetBSD 8 amd64 build
Ubuntu 16.04 amd64 build
Ubuntu 14.04 amd64 build
Ubuntu 12.04 amd64 build
Debian 8 amd64 build

blocking comments addressed

NetDEF-CI · 2019-12-20T07:30:03Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10180/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

FreeBSD 11 amd64 build: Failed (click for details)

Make failed for FreeBSD 11 amd64 build:
(see full Make log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10180/artifact/CI009BUILD/ErrorLog/log_make.txt)

  CC       lib/json.lo
  CC       lib/keychain.lo
  CC       lib/lib_errors.lo
  CC       lib/libfrr.lo
  CC       lib/linklist.lo
  CC       lib/log.lo
  CLIPPY   lib/log_vty_clippy.c
  CC       lib/log_vty.lo
  CC       lib/md5.lo

FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10180/artifact/CI009BUILD/config.status/config.status

Successful on other platforms

Ubuntu 14.04 amd64 build
Ubuntu 18.04 amd64 build
FreeBSD 12 amd64 build
Ubuntu 16.04 i386 build
Debian 8 amd64 build
Debian 9 amd64 build
Ubuntu 18.04 ppc64le build
OpenBSD 6 amd64 build
NetBSD 8 amd64 build
NetBSD 6 amd64 build
Ubuntu 16.04 amd64 build
CentOS 7 amd64 build
Ubuntu 12.04 amd64 build
Debian 10 amd64 build
Fedora 29 amd64 build

vishaldhingra · 2019-12-20T08:57:23Z

frr-staticd tree.pdf

NetDEF-CI · 2020-01-17T14:31:52Z

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10479/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

CLANG Static Analyzer Summary

Github Pull Request 5460, comparing to Git base SHA 7d75ef8

No Changes in Static Analysis warnings compared to base

1 Static Analyzer issues remaining.

See details at
https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10479/artifact/shared/static_analysis/index.html

vishaldhingra · 2020-01-24T09:09:32Z

mjstapp · 2020-01-24T15:27:30Z

yang/frr-staticd.yang

+      "Support for a 'static' pseudo-protocol instance
+       consists of a list of routes.";
+
+      list address-family {


Where does vrf come into this? I only see unqualified ip prefixes: are the vrfs captured somewhere else?

vrf would come from the frr-routing.yang
It would be like this
module: frr-routing
+--rw routing
+--rw control-plane-protocols
+--rw control-plane-protocol* [type name vrf]
+--rw type identityref
+--rw name string
+--rw vrf frr-vrf:vrf-ref
+--rw frr-staticd:staticd
+--rw frr-staticd:address-family* [address-family]

mjstapp · 2020-01-24T15:28:28Z

yang/frr-staticd.yang

+        + "frr-rt:control-plane-protocol/staticd/address-family/"
+        + "ipv4-route/frr-staticd-next-hop/frr-nexthops/nexthops" {
+
+    leaf distance {


I think both distance and tag are properties of a static route, not of each nexthop in a route? check lib/zclient.h to see how those attributes are conveyed.

Actually at present in staticd, if you go to the static_route struct, then tag and distance are defined in this struct means part of nexthop. Now when route goes to zebra then these attributes becomes part of route.

qlyoung · 2020-01-24T16:00:30Z

IMO routes should not be segmented into containers by AF, there should be a flat list and the AF should be an attribute of the route

NetDEF-CI · 2020-01-30T12:56:10Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10566/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

FreeBSD 11 amd64 build: Failed (click for details)

FreeBSD 11 amd64 build: No useful log found

Successful on other platforms

Ubuntu 16.04 amd64 build
Ubuntu 14.04 amd64 build
Ubuntu 16.04 i386 build
Ubuntu 18.04 amd64 build
Debian 8 amd64 build
NetBSD 6 amd64 build
CentOS 7 amd64 build
Ubuntu 18.04 ppc64le build
Debian 9 amd64 build
OpenBSD 6 amd64 build
Ubuntu 12.04 amd64 build
NetBSD 8 amd64 build
Fedora 29 amd64 build
FreeBSD 12 amd64 build
Debian 10 amd64 build

NetDEF-CI · 2020-01-30T23:14:36Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10566/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

FreeBSD 11 amd64 build: Failed (click for details)

Make failed for FreeBSD 11 amd64 build:
(see full Make log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10566/artifact/CI009BUILD/ErrorLog/log_make.txt)

 9595 |    CPP_NOTICE(
ospfd/ospf_neighbor.c: In function 'ospf_nbr_lookup':
ospfd/ospf_neighbor.c:410:45: error: taking address of packed member of 'struct ip' may result in an unaligned pointer value [-Werror=address-of-packed-member]
cc1: all warnings being treated as errors
gmake[1]: *** [Makefile:7472: ospfd/ospf_neighbor.o] Error 1
In file included from ./lib/yang_wrappers.h:23,
eigrpd/eigrp_packet.c: In function 'eigrp_read':
eigrpd/eigrp_packet.c:552:25: error: taking address of packed member of 'struct ip' may result in an unaligned pointer value [-Werror=address-of-packed-member]
./lib/prefix.h:344:46: note: in definition of macro 'IPV4_ADDR_SAME'

FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10566/artifact/CI009BUILD/config.status/config.status

Successful on other platforms

Ubuntu 16.04 amd64 build
Ubuntu 14.04 amd64 build
Ubuntu 16.04 i386 build
Ubuntu 18.04 amd64 build
Debian 8 amd64 build
NetBSD 6 amd64 build
CentOS 7 amd64 build
Ubuntu 18.04 ppc64le build
Debian 9 amd64 build
OpenBSD 6 amd64 build
Ubuntu 12.04 amd64 build
NetBSD 8 amd64 build
Fedora 29 amd64 build
FreeBSD 12 amd64 build
Debian 10 amd64 build

vishaldhingra · 2020-01-31T13:12:47Z

NetDEF-CI · 2020-02-04T11:34:51Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10600/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

FreeBSD 11 amd64 build: Failed (click for details)

Make failed for FreeBSD 11 amd64 build:
(see full Make log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10600/artifact/CI009BUILD/ErrorLog/log_make.txt)

 9595 |    CPP_NOTICE(
ospfd/ospf_neighbor.c: In function 'ospf_nbr_lookup':
ospfd/ospf_neighbor.c:410:45: error: taking address of packed member of 'struct ip' may result in an unaligned pointer value [-Werror=address-of-packed-member]
cc1: all warnings being treated as errors
gmake[1]: *** [Makefile:7472: ospfd/ospf_neighbor.o] Error 1
In file included from ./lib/yang_wrappers.h:23,
eigrpd/eigrp_packet.c: In function 'eigrp_read':
eigrpd/eigrp_packet.c:552:25: error: taking address of packed member of 'struct ip' may result in an unaligned pointer value [-Werror=address-of-packed-member]
./lib/prefix.h:344:46: note: in definition of macro 'IPV4_ADDR_SAME'

FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10600/artifact/CI009BUILD/config.status/config.status

Successful on other platforms

NetBSD 8 amd64 build
Ubuntu 16.04 amd64 build
Ubuntu 16.04 i386 build
Ubuntu 18.04 amd64 build
NetBSD 6 amd64 build
CentOS 7 amd64 build
Debian 9 amd64 build
Debian 8 amd64 build
Ubuntu 12.04 amd64 build
Ubuntu 14.04 amd64 build
Ubuntu 18.04 ppc64le build
OpenBSD 6 amd64 build
Fedora 29 amd64 build
Debian 10 amd64 build
FreeBSD 12 amd64 build

Warnings Generated during build:

Debian 10 amd64 build: Successful with additional warnings

Debian Package lintian failed for Debian 10 amd64 build:
(see full package build log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10600/artifact/DEB10BUILD/ErrorLog/log_lintian.txt)

W: frr source: pkg-js-tools-test-is-missing
W: frr source: pkg-js-tools-test-is-missing
W: frr-snmp: changelog-file-missing-explicit-entry 6.0-2 -> 7.3-dev-20200204-00-gef5a6aa58-0 (missing) -> 7.3-dev-20200204-00-gef5a6aa58-0~deb10u1
W: frr: changelog-file-missing-explicit-entry 6.0-2 -> 7.3-dev-20200204-00-gef5a6aa58-0 (missing) -> 7.3-dev-20200204-00-gef5a6aa58-0~deb10u1
W: frr: spelling-error-in-readme-debian explecitly explicitly
W: frr-pythontools: changelog-file-missing-explicit-entry 6.0-2 -> 7.3-dev-20200204-00-gef5a6aa58-0 (missing) -> 7.3-dev-20200204-00-gef5a6aa58-0~deb10u1
W: frr-rpki-rtrlib: changelog-file-missing-explicit-entry 6.0-2 -> 7.3-dev-20200204-00-gef5a6aa58-0 (missing) -> 7.3-dev-20200204-00-gef5a6aa58-0~deb10u1
W: frr-doc: changelog-file-missing-explicit-entry 6.0-2 -> 7.3-dev-20200204-00-gef5a6aa58-0 (missing) -> 7.3-dev-20200204-00-gef5a6aa58-0~deb10u1

NetDEF-CI · 2020-02-05T06:17:27Z

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10620/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

OpenBSD 6 amd64 build: Failed (click for details)

DejaGNU Unittests (make check) failed for OpenBSD 6 amd64 build:
(see full PyTest log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10620/artifact/CI011BUILD/ErrorLog/log_pytests.txt)

=================================== FAILURES ===================================
_________________________ TestMpath.test_exit_cleanly __________________________
self = <test_mpath.TestMpath object at 0x151907edca20>
    def testfunction(self):
        self._run_tests()
        result = self.testresults[matchfunction]
        if result is not None:
>           frrsix.reraise(*result)
helpers/python/frrtest.py:101: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
helpers/python/frrsix.py:57: in reraise
    raise value
helpers/python/frrtest.py:76: in _run_tests
    test(self)
helpers/python/frrtest.py:94: in matchfunction
    method(self, *args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <test_mpath.TestMpath object at 0x151907edca20>
    def _exit_cleanly(self):
        if self.exitcode != 0:
>           raise MultiTestFailure("Program did not terminate with exit code 0")
E           frrtest.MultiTestFailure: Program did not terminate with exit code 0
helpers/python/frrtest.py:84: MultiTestFailure
----------------------------- Captured stderr call -----------------------------
2020/02/04 22:07:34 unknown: [EC 100663299] buffer_write: write error on fd 0: Bad file descriptor
2020/02/04 22:07:34 unknown: [EC 100663302] zclient_send_message: buffer_write failed to zclient fd 0, closing
___________________ TestMpath.test_bgp_maximum_paths_config ____________________
self = <test_mpath.TestMpath object at 0x1519ce825278>
    def testfunction(self):
        self._run_tests()
        result = self.testresults[matchfunction]
        if result is not None:
>           frrsix.reraise(*result)
helpers/python/frrtest.py:101: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
helpers/python/frrsix.py:57: in reraise
    raise value
helpers/python/frrtest.py:76: in _run_tests
    test(self)
helpers/python/frrtest.py:94: in matchfunction
    method(self, *args, **kwargs)
helpers/python/frrtest.py:143: in _okfail
    self._onesimple(line)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <test_mpath.TestMpath object at 0x151907edca20>
line = b'bgp maximum-paths config'
    def _onesimple(self, line):
        if type(line) is str:
            line = line.encode('utf8')
        idx = self.output.find(line)
        if idx != -1:
            self.output = self.output[idx+len(line):]
        else:
>           raise MultiTestFailure("%r could not be found" % line)
E           frrtest.MultiTestFailure: b'bgp maximum-paths config' could not be found
helpers/python/frrtest.py:140: MultiTestFailure
__________________________ TestMpath.test_bgp_mp_list __________________________
self = <test_mpath.TestMpath object at 0x1519d52a47f0>
    def testfunction(self):
        self._run_tests()
        result = self.testresults[matchfunction]
        if result is not None:
>           frrsix.reraise(*result)
helpers/python/frrtest.py:101: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
helpers/python/frrsix.py:57: in reraise
    raise value
helpers/python/frrtest.py:76: in _run_tests
    test(self)
helpers/python/frrtest.py:94: in matchfunction
    method(self, *args, **kwargs)
helpers/python/frrtest.py:143: in _okfail
    self._onesimple(line)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <test_mpath.TestMpath object at 0x151907edca20>, line = b'bgp_mp_list'
    def _onesimple(self, line):
        if type(line) is str:
            line = line.encode('utf8')
        idx = self.output.find(line)
        if idx != -1:
            self.output = self.output[idx+len(line):]
        else:
>           raise MultiTestFailure("%r could not be found" % line)
E           frrtest.MultiTestFailure: b'bgp_mp_list' could not be found
helpers/python/frrtest.py:140: MultiTestFailure
__________________ TestMpath.test_bgp_path_info_mpath_update ___________________
self = <test_mpath.TestMpath object at 0x1519ce832898>
    def testfunction(self):
        self._run_tests()
        result = self.testresults[matchfunction]
        if result is not None:
>           frrsix.reraise(*result)
helpers/python/frrtest.py:101: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
helpers/python/frrsix.py:57: in reraise
    raise value
helpers/python/frrtest.py:76: in _run_tests
    test(self)
helpers/python/frrtest.py:94: in matchfunction
    method(self, *args, **kwargs)
helpers/python/frrtest.py:143: in _okfail

OpenBSD 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10620/artifact/CI011BUILD/config.status/config.status

Successful on other platforms

Debian 10 amd64 build
Debian 8 amd64 build
FreeBSD 11 amd64 build
Fedora 29 amd64 build
NetBSD 6 amd64 build
CentOS 7 amd64 build
Ubuntu 18.04 amd64 build
FreeBSD 12 amd64 build
Debian 9 amd64 build
Ubuntu 18.04 ppc64le build
NetBSD 8 amd64 build
Ubuntu 16.04 amd64 build
Ubuntu 12.04 amd64 build
Ubuntu 14.04 amd64 build
Ubuntu 16.04 i386 build

Warnings Generated during build:

Debian 10 amd64 build: Successful with additional warnings

Debian Package lintian failed for Debian 10 amd64 build:
(see full package build log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10620/artifact/DEB10BUILD/ErrorLog/log_lintian.txt)

W: frr source: pkg-js-tools-test-is-missing
W: frr source: pkg-js-tools-test-is-missing
W: frr-doc: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g8141e5478-0 (missing) -> 7.4-dev-20200205-01-g8141e5478-0~deb10u1
W: frr-snmp: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g8141e5478-0 (missing) -> 7.4-dev-20200205-01-g8141e5478-0~deb10u1
W: frr-rpki-rtrlib: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g8141e5478-0 (missing) -> 7.4-dev-20200205-01-g8141e5478-0~deb10u1
W: frr: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g8141e5478-0 (missing) -> 7.4-dev-20200205-01-g8141e5478-0~deb10u1
W: frr-pythontools: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g8141e5478-0 (missing) -> 7.4-dev-20200205-01-g8141e5478-0~deb10u1

NetDEF-CI · 2020-02-05T09:07:21Z

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10618/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Warnings Generated during build:

Debian 10 amd64 build: Successful with additional warnings

Debian Package lintian failed for Debian 10 amd64 build:
(see full package build log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10618/artifact/DEB10BUILD/ErrorLog/log_lintian.txt)

W: frr source: pkg-js-tools-test-is-missing
W: frr source: pkg-js-tools-test-is-missing
W: frr: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g4491b1903-0 (missing) -> 7.4-dev-20200205-01-g4491b1903-0~deb10u1
W: frr-snmp: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g4491b1903-0 (missing) -> 7.4-dev-20200205-01-g4491b1903-0~deb10u1
W: frr-rpki-rtrlib: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g4491b1903-0 (missing) -> 7.4-dev-20200205-01-g4491b1903-0~deb10u1
W: frr-doc: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g4491b1903-0 (missing) -> 7.4-dev-20200205-01-g4491b1903-0~deb10u1
W: frr-pythontools: changelog-file-missing-explicit-entry 6.0-2 -> 7.4-dev-20200205-01-g4491b1903-0 (missing) -> 7.4-dev-20200205-01-g4491b1903-0~deb10u1

Yang files for staticd to use northbound APIs Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: vishaldhingra <vdhingra@vmware.com> Signed-off-by: vishaldhingra <vdhingra@vmware.com>

vishaldhingra · 2020-02-07T09:48:58Z

NetDEF-CI · 2020-02-07T11:09:10Z

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10656/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

NetDEF-CI · 2020-02-07T13:13:16Z

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-10661/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

qlyoung · 2020-02-11T16:50:01Z

Good to merge after NH model goes in.

addressed

polychaeta added the staticd label Dec 3, 2019

srimohans changed the title ~~staticd: yang defination~~ staticd: yang definition Dec 3, 2019

satheeshkarra suggested changes Dec 3, 2019

View reviewed changes

Spantik mentioned this pull request Dec 3, 2019

FRR Northbound Migration Roadmap #5428

Open

qlyoung self-requested a review December 3, 2019 16:33

vishaldhingra force-pushed the static_nb branch from 67ac93e to 255439c Compare December 4, 2019 12:01

vishaldhingra force-pushed the static_nb branch from 255439c to d2d8a29 Compare December 4, 2019 12:54

This comment has been minimized.

Sign in to view

qlyoung previously requested changes Dec 4, 2019

View reviewed changes

vishaldhingra force-pushed the static_nb branch from d2d8a29 to 54bead9 Compare December 10, 2019 13:31

polychaeta previously requested changes Dec 10, 2019

View reviewed changes

vishaldhingra force-pushed the static_nb branch from 54bead9 to 9ab4f01 Compare December 10, 2019 13:33

polychaeta previously requested changes Dec 10, 2019

View reviewed changes

vishaldhingra force-pushed the static_nb branch from 9ab4f01 to 62c7633 Compare December 10, 2019 13:35

polychaeta previously requested changes Dec 10, 2019

View reviewed changes

vishaldhingra force-pushed the static_nb branch from f9e0eae to 743cfc2 Compare December 20, 2019 07:00

vishaldhingra force-pushed the static_nb branch from 743cfc2 to 71c41b7 Compare January 17, 2020 11:55

mjstapp reviewed Jan 24, 2020

View reviewed changes

vishaldhingra force-pushed the static_nb branch from 71c41b7 to b96d61a Compare January 30, 2020 12:31

vishaldhingra force-pushed the static_nb branch from b96d61a to ef5a6aa Compare February 4, 2020 11:07

vishaldhingra force-pushed the static_nb branch 2 times, most recently from 4491b19 to 8141e54 Compare February 5, 2020 05:50

vishaldhingra force-pushed the static_nb branch from 8141e54 to f4ebdbe Compare February 7, 2020 07:44

staticd: yang defination

95f1804

Yang files for staticd to use northbound APIs Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: vishaldhingra <vdhingra@vmware.com> Signed-off-by: vishaldhingra <vdhingra@vmware.com>

vishaldhingra force-pushed the static_nb branch from f4ebdbe to 95f1804 Compare February 7, 2020 09:47

Spantik added the review & merge me look at me! label Feb 10, 2020

qlyoung merged commit 2a9ca11 into FRRouting:nb_conversions Feb 14, 2020

staticd: yang definition #5460

staticd: yang definition #5460

Conversation

vishaldhingra commented Dec 3, 2019 • edited Loading

Spantik commented Dec 3, 2019 • edited Loading

satheeshkarra commented Dec 3, 2019 • edited by qlyoung Loading

Spantik commented Dec 3, 2019

satheeshkarra commented Dec 3, 2019

Spantik commented Dec 3, 2019

satheeshkarra commented Dec 3, 2019

Spantik commented Dec 3, 2019

NetDEF-CI commented Dec 3, 2019

Continuous Integration Result: SUCCESSFUL

CLANG Static Analyzer Summary

No Changes in Static Analysis warnings compared to base

1 Static Analyzer issues remaining.

satheeshkarra left a comment

Choose a reason for hiding this comment

vishaldhingra commented Dec 4, 2019 • edited Loading

vishaldhingra commented Dec 4, 2019 • edited Loading

satheeshkarra commented Dec 4, 2019

This comment has been minimized.

This comment has been minimized.

qlyoung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qlyoung Dec 4, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Spantik Dec 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Spantik Dec 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rwestphal commented Dec 7, 2019

qlyoung commented Dec 7, 2019 via email

Spantik commented Dec 9, 2019

polychaeta left a comment

Choose a reason for hiding this comment

polychaeta left a comment

Choose a reason for hiding this comment

polychaeta left a comment

Choose a reason for hiding this comment

NetDEF-CI commented Dec 20, 2019

Continuous Integration Result: FAILED

Get source / Pull Request: Successful

Building Stage: Failed

NetDEF-CI commented Dec 20, 2019

Continuous Integration Result: FAILED

Get source / Pull Request: Successful

Building Stage: Failed

vishaldhingra commented Dec 20, 2019

NetDEF-CI commented Jan 17, 2020

Continuous Integration Result: SUCCESSFUL

CLANG Static Analyzer Summary

No Changes in Static Analysis warnings compared to base

1 Static Analyzer issues remaining.

vishaldhingra commented Jan 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qlyoung commented Jan 24, 2020

NetDEF-CI commented Jan 30, 2020

Continuous Integration Result: FAILED

Get source / Pull Request: Successful

Building Stage: Failed

NetDEF-CI commented Jan 30, 2020

Continuous Integration Result: FAILED

vishaldhingra commented Dec 3, 2019 •

edited

Loading

Spantik commented Dec 3, 2019 •

edited

Loading

satheeshkarra commented Dec 3, 2019 •

edited by qlyoung

Loading

vishaldhingra commented Dec 4, 2019 •

edited

Loading

vishaldhingra commented Dec 4, 2019 •

edited

Loading

qlyoung Dec 4, 2019 •

edited

Loading

Spantik Dec 6, 2019 •

edited

Loading

Spantik Dec 6, 2019 •

edited

Loading