You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Addresses  CPS-43 - Getting issue details... STATUS


Cases

Augmentation

The augmentation is mainly used to extends an existing model. The augmentation is encapsulated within separate
module file, having own namespace and revision. Example:

base.yang
module base {
    yang-version 1.1;

    namespace "org:onap:cps:test:base";
    revision "2020-01-01";
    prefix "base";

    container base-container {
        leaf name {
            type string;
        }
        leaf description {
            type string;
        }
    }
}
augment.yang
module augment {
    yang-version 1.1;

    namespace "org:onap:cps:test:augment";
    revision "2020-01-02";
    prefix "augment";

    import base {
        prefix "base";
    }

    grouping augment-group {
         leaf augmented-leaf {
             type string;
         }
    }

    augment "base:base-container" {
        uses augment-group;
    }
}
augment.json
{
  "base-container": {
    "name": "test name",
    "description": "test description",
    "augmented-leaf": "more information"
  }
}

Empty module issue

When files are processed the effective model is referenced by name, namespace and revision of a base module, which are not changed and remain same.
At the same time the augment module became extra, because it contains no model so it won't be ever referenced (directly) for data validation.

Imports

The imports are mainly used to re-use definitions from existing modules.

importer.yang
module base {
    yang-version 1.1;

    namespace "org:onap:cps:test:importer";
    revision "2020-02-01";
    prefix "importer";

    import exporter {
        prefix "exporter";
    }

    container importer-container {
        leaf name {
            type string;
        }
        leaf description {
            type string;
        }
        uses "exporter:export-group";
    }
}
exporter.yang
module exporter {
    yang-version 1.1;

    namespace "org:onap:cps:test:exporter";
    revision "2020-02-02";
    prefix "exporter";

    grouping export-group {
         leaf exporter-leaf {
             type string;
         }
    }

    container exporter-container {
        uses export-group;
    }
}

importer.json (valid)
{
  "importer-container": {
    "name": "test name",
    "description": "test description",
    "exporter-leaf": "test imported"
  }
}
exporter.json (also valid)
{
  "exporter-container": {
    "exporter-leaf": "test data"
  }
}

Multiple valid models issue

When the data is being decomposed using a schema context built from these two yang files, there will be no any error
if the incoming JSON matches any of models within . The appropriate module (for validation/parsing) could be chosen
dynamically. It also possible there could be collision if root container elements of both modules are having same name.

Assembly using submodules

Assembly case is mainly used to for organizational purposes when large module file is split to logical peaces (submodules)
for better maintainability

assembly.yang
module assembly {
    yang-version 1.1;

    namespace "org:onap:cps:test:assembly";
    prefix "assembly";
    revision "2020-03-01";

    include "component";

    container module-container {
        leaf name {
            type string;
        }
        leaf description {
            type string;
        }
    }
}
component.yang
submodule component {
    yang-version 1.1;

    revision "2020-03-02";

    belongs-to "assembly" {
        prefix "assembly";
    }

    container submodule-container {
        leaf name {
            type string;
        }
        leaf description {
            type string;
        }
    }
}
assembly.json (invalid)
{
  "module-container": {
    "name": "module name",
    "description": "module description"
  },
  "submodule-container": {
    "name": "submodule name",
    "description": "submodule description"
  }
}

Module vs Yang File

  • No labels