[Feature Request] Generate yaml files from Yang models

[jean-christophe-manciot]

Goal

The goal is to automate the configuration with Ansible.

Example

Source: all openconfig interfaces models Destination: a combined interfaces.yml:

openconfig-interfaces:
  interfaces:
    interface:
        name:           # string
        config:
          name:         # string
          type:        
                        # softwareLoopback | ethernet-csmacd | ieee8023adLag | 
                        # l2vlan (L2 802.1Q) | l3ipvlan (L3 802.1Q)
                        # https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-5
          mtu:          # uint16
          description:  # string
          enabled:      # boolean
        state:
          name:         # string
          type:         # softwareLoopback | ethernet-csmacd | ieee8023adLag | 
                        # l2vlan (L2 802.1Q) | l3ipvlan (L3 802.1Q)
                        # https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-5
          mtu:          # uint16
          description:  # string
          enabled:      # boolean
          ifindex:      # uint32
          admin_status: # enumeration
          oper_status:  # enumeration
          last_change:  # oc-types:timeticks64
          counters:
            in_octets:              # oc-yang:counter64
            in_unicast_pkts:        # oc-yang:counter64
            in_broadcast_pkts:      # oc-yang:counter64
            in_multicast_pkts:      # oc-yang:counter64
            in_discards:            # oc-yang:counter64
            in_errors:              # oc-yang:counter64
            in_unknown_protos:      # oc-yang:counter64
            out_octets:             # oc-yang:counter64
            out_unicast_pkts:       # oc-yang:counter64
            out_broadcast_pkts:     # oc-yang:counter64
            out_multicast_pkts:     # oc-yang:counter64
            out_discards:           # oc-yang:counter64
            out_errors:             # oc-yang:counter64
            last_clear:             # oc-types:timeticks64
        aggregation:
          config:
            lag-type:    # LACP | STATIC
            min-links:   # uint16
          state:
            lag-type:    # LACP | STATIC
            min-links:   # uint16
            lag-speed:   # uint32
            member:      # oc-if:base-interface-ref
          switched-vlan:
            config:
              interface-mode:   # ACCESS | TRUNK
              native-vlan:      # vlan-id | qinq-id
              access-vlan:      # vlan-id | qinq-id
              trunk-vlans:      # vlan-id | qinq-id
            state:
              interface-mode:   # ACCESS | TRUNK
              native-vlan:      # vlan-id | qinq-id
              access-vlan:      # vlan-id | qinq-id
              trunk-vlans:      # vlan-id | qinq-id
        vlan:
          config:
            vlan-id:   # vlan-id | qinq-id
          state:
            vlan-id:   # vlan-id | qinq-id
        ethernet:
...

[111pontes]

Encoding YANG data with YAML is actually orthogonal to Ansible automation. Today, you can easily implement Ansible modules using YDK (https://github.com/111pontes/xr-pl2/tree/master/ansible/ip_destination_reachable). As there are multiple on-going efforts in this area, we need to carefully analyze what enhancements we should pursue.

[jean-christophe-manciot]

@111pontes

1. I'm not sure what you mean by orthogonal, but the data must be formatted in YAML for ansible existing modules to be able to read them.
2. The module you advertise shows some specific implementation of a module using Netconf. I intend to use RESTconf instead.
3. There is no need to develop new ansible modules in python to be able to use Yang data models to automate devices.

[111pontes]

1. Enconding data in YAML can be convenient, but it's not really mandatory for leveraging data models in Ansible
2. The use of NETCONF in that model was fortuitous. It could equally use RESTCONF or gRPC.
3. Agree. It all depends on the level of abstraction one is trying to provide.

Support for YAML encoding is something we've discussed frequently. I'm a big fan of the idea. No disagreement there.