Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

staticd: yang definition #5460

Merged
merged 1 commit into from Feb 14, 2020
Merged

Conversation

@vishaldhingra
Copy link
Contributor

@vishaldhingra vishaldhingra commented Dec 3, 2019

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
Copy link
Member

@Spantik Spantik commented Dec 3, 2019

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.

Screenshot 2019-12-03 at 7 42 33 PM

Screenshot 2019-12-03 at 7 42 46 PM

@satheeshkarra
Copy link
Contributor

@satheeshkarra satheeshkarra commented Dec 3, 2019

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
Copy link
Member

@Spantik Spantik commented Dec 3, 2019

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

@srimohans srimohans changed the title staticd: yang defination staticd: yang definition Dec 3, 2019
@satheeshkarra
Copy link
Contributor

@satheeshkarra satheeshkarra commented Dec 3, 2019

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
Copy link
Member

@Spantik Spantik commented Dec 3, 2019

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
Copy link
Contributor

@satheeshkarra satheeshkarra commented Dec 3, 2019

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
Copy link
Member

@Spantik Spantik commented Dec 3, 2019

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Dec 3, 2019

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

Copy link
Contributor

@satheeshkarra satheeshkarra left a comment

Please take care of Negative cases also

@vishaldhingra
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Dec 4, 2019

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
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Dec 4, 2019

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
Copy link
Contributor

@satheeshkarra satheeshkarra commented Dec 4, 2019

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.

@NetDEF-CI

This comment has been hidden.

@NetDEF-CI

This comment has been hidden.

Copy link
Member

@qlyoung qlyoung left a comment

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

case ifname {
leaf outgoing-interface {
type string {
length "1..16";
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

Any reason this shouldn't be an interface leafref?

Copy link
Contributor Author

@vishaldhingra vishaldhingra Dec 11, 2019

done

case gateway {
leaf gw-interface {
type string {
length "1..16";
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

Any reason this shouldn't be an interface leafref?

Copy link
Contributor Author

@vishaldhingra vishaldhingra Dec 11, 2019

done

description
"Name of the outgoing interface.";
}
leaf is-onlink {
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

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.

Copy link
Contributor Author

@vishaldhingra vishaldhingra Dec 11, 2019

done

case Null0 {
leaf Null0 {
type boolean;
default false;
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

Please remember to use yanglint to format the models

}
}
case Null0 {
leaf Null0 {
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

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.

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

@qlyoung qlyoung Dec 4, 2019

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?

Copy link
Member

@Spantik Spantik Dec 6, 2019

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

Copy link
Member

@qlyoung qlyoung Dec 6, 2019

Sounds good

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

@qlyoung qlyoung Dec 4, 2019

Ditto previous comment regarding leafrefs.

"vrf name.";
leaf name {
type string {
length "1..36";
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

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

Copy link
Contributor Author

@vishaldhingra vishaldhingra Dec 11, 2019

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

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

@qlyoung qlyoung Dec 4, 2019

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

Copy link
Member

@Spantik Spantik Dec 6, 2019

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

@@ -0,0 +1,1123 @@
module ietf-interfaces {
Copy link
Member

@qlyoung qlyoung Dec 4, 2019

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
Copy link
Member

@rwestphal rwestphal commented Dec 7, 2019

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
Copy link
Member

@qlyoung qlyoung commented Dec 7, 2019

@Spantik
Copy link
Member

@Spantik Spantik commented Dec 9, 2019

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.

Copy link

@polychaeta polychaeta left a comment

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.

Copy link

@polychaeta polychaeta left a comment

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.

Copy link

@polychaeta polychaeta left a comment

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Dec 20, 2019

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

@polychaeta polychaeta dismissed their stale review Dec 20, 2019

blocking comments addressed

@NetDEF-CI
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Dec 20, 2019

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
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Dec 20, 2019

@NetDEF-CI
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Jan 17, 2020

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
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Jan 24, 2020

Staticd-yang-tree

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

list address-family {
Copy link
Contributor

@mjstapp mjstapp Jan 24, 2020

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

Copy link
Contributor Author

@vishaldhingra vishaldhingra Jan 24, 2020

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]

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

leaf distance {
Copy link
Contributor

@mjstapp mjstapp Jan 24, 2020

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.

Copy link
Contributor Author

@vishaldhingra vishaldhingra Jan 24, 2020

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
Copy link
Member

@qlyoung qlyoung commented Jan 24, 2020

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Jan 30, 2020

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Jan 30, 2020

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
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Jan 31, 2020

static_yang

@NetDEF-CI
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Feb 4, 2020

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

@vishaldhingra vishaldhingra force-pushed the static_nb branch 2 times, most recently from 4491b19 to 8141e54 Feb 5, 2020
@NetDEF-CI
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Feb 5, 2020

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Feb 5, 2020

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
Copy link
Contributor Author

@vishaldhingra vishaldhingra commented Feb 7, 2020

static_yang

@NetDEF-CI
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Feb 7, 2020

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
Copy link
Collaborator

@NetDEF-CI NetDEF-CI commented Feb 7, 2020

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
Copy link
Member

@qlyoung qlyoung commented Feb 11, 2020

Good to merge after NH model goes in.

@qlyoung qlyoung dismissed their stale review Feb 11, 2020

addressed

@qlyoung qlyoung merged commit 2a9ca11 into FRRouting:nb_conversions Feb 14, 2020
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants