...
While we have clear dependencies of yang described module on context (surrounding modules) it's possible there could
be several modules within same dataspace having same namespace, name and revision+name+revision combination, so these parameters are no
longer can be used as unique module identifiers. The actual module set (context) the is now important, while namespace
and revision became obsolete.
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Solution proposal
Due to the each module isn't used out of context (surrounding/neighbor modules) it makes sense to manage them as an
indivisible immutable entity. On update all the modules are expected to be provided as input data and used to replace
all the existing modules (associated with). It make unnecessary to persist source files.
Due to there is no sense to use any standalone module out of context, it makes sense to store persist module as single unit
as well (API/SPI). It will be easier to extract whole context when data is validated vs model. It will require the anchor to
reference a particular module within a defined moduleset.
The input data is expected to be provided as single file: either single yang file (set of single source file) or a zip file (multiple
yang files). The file type to be recognized as extension. This will allow to simplify the REST API - same endpoint can be used to
serve multiple modulesets. In further perspective it makes sense to add additional to a moduleset entity for easier
management/maintenance like version and enabled/disabled flag.
To Discuss/ To Decide
- Confirm / alternate the proposal
- Change moduleset naming/referencing - e.g. Package, Context