Addresses:  CPS-352 - Getting issue details... STATUS


PLease note further update on CPS-872 CM Handle State: define and agree new dmi-registry yang model supporting States

Problem description

Yang model need to be created in CPS to persist relationship between DMI-plugin and CM-handle. Also, DMI-plugin connection data and additional parameters needed to be persisted.
Under this ticket, we need to create yang-model for above statements and persist that into cps repository.

Proposal

Please find below yang-model for above problem, also a new dataspace will be added named dmi-registry. Using liquibase db changes will be done.




Alternative 2 is suggested

  • Simplicity
  • Can be migrated to  alternative 1 if needed
  • Unlikely Additional fields are ever required (the can be stored per cmHandle instead)
Yang Model 
module dmi-registry {

  yang-version 1.1;

  namespace "org:onap:cps:ncmp";

  prefix dmi-reg;

  organization "Ericsson Software Tech.";

  contact "rahul.tyagi@est.tech";

  revision "2021-05-20" {
    description
    "Initial Version";
  }

  container dmi-registry {

    list cm-handle {

      key "id";

      leaf id {
        type string;
      }

      leaf dmi-service-name {
        type string;
      }

      list additional-properties {

        key "name";

        leaf name {
          type string;
        }

        leaf value {
          type string;
        }
      }
    }
  }
}

Update October 2021

CPS-736 - Getting issue details... STATUS

Added dmi-data-service-name & dmi-model-service-name to allow separate DMI instances for each responsibility


October 2021 Updated Yang Model 
module dmi-registry {

  yang-version 1.1;

  namespace "org:onap:cps:ncmp";

  prefix dmi-reg;

  revision "2021-10-20" {
    description
    "Added dmi-data-service-name & dmi-model-service-name to allow separate DMI instances for each responsibility";
   }

  revision "2021-05-20" {
    description
    "Initial Version";
  }

  container dmi-registry {

    list cm-handles {

      key "id";

      leaf id {
        type string;
      }

      leaf dmi-service-name {
        type string;
      }

      leaf dmi-data-service-name {
        type string;
      }

      leaf dmi-model-service-name {
        type string;
      }

      list additional-properties {

        key "name";

        leaf name {
          type string;
        }

        leaf value {
          type string;
        }
      }
    }
  }
}  
  • No labels

8 Comments

  1. Toine Siebelink

    unfortunately still cannot make inline comments inside code block, so I enabled line numbers:

    #5 need definite name, not 'sample' 

    #19 the target assume it is an ip address. I thought we have mount points instead? In any case can we make it more generic : an single address string that can contain an ip-address with port or anything else

    #71 not sure if 'refinement' of target is need, it is oly used once, might as well declare and describe it as a dmi-plugin-target in the grouping definition on line #18

    #79 no need for dmi-plugin data, Lets not code for the future...




    1. Rahul Tyagi

      Toine Siebelink for #19 this target is actually address/port of dmi-plugin and less to do with mount of device on sdnc. For device mount point we need to know the device id. for eg on sdnc a mount point will look like this

      {
            "node-id": "PNFDemo",
            "netconf-node-topology:protocol": {
              "name": "TLS"
            },
            "netconf-node-topology:host": "172.17.0.1",
            "netconf-node-topology:key-based": {
              "username": "netconf",
              "key-id": "ODL_private_key_0"
            },
            "netconf-node-topology:port": 6513,
            "netconf-node-topology:tcp-only": false,
            "netconf-node-topology:max-connection-attempts": 5
          },

      so cps/dmi-plugin need to know node-id i.e PNFDemo. We can discuss it how and where to get it. Rest comments, I'll take care.

      1. Toine Siebelink

        ok, I mixed them up, the word 'target' put me on the wrong footing (smile)

        A related question then, can we handle IPV6 using the same 2 fields, do we need to know it is a IPV6 adress or can we deduce from the content or do we simply not case and assume the address is populate using the correct formatting for IPV6 or 4....

        1. Rahul Tyagi

          Address field and persist any string whether its ipv4 or ipv6, it upto the parser to identify which kind of address it is. If we add constraint than we can restrict any wrong address. what is your suggestion here.

          1. Toine Siebelink

            I think we agree, leave it open and we can parse the string to find out if it is an ipv4 or 6 address. If we are parsing anyway I would suggest to have just one address field which can include port where needed

  2. Toine Siebelink

    sorry, forgot to mention 

    #44 the term used so far in conversation and documentation was 'additional-properties' maybe lets stick with that

  3. Toine Siebelink

    responsabilty
    fix spelling in yang file above. Wil keep an eye out for it in code review

    1. Joseph Keenan

      Done