Bugzilla – Full Text Bug Listing
| Summary: | modifiableAttributes in Vnfd is unusable as is. | ||
|---|---|---|---|
| Product: | NFV | Reporter: | Mahesh Jethanandani <mjethanandan> |
| Component: | GS NFV-SOL 006 Yang model | Assignee: | Bruno Chatras <bruno.chatras> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | michele.carignani |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows | ||
| Version number of the related document: | OpenAPI issue category: | --- | |
The WG (in particular the chair) demonstrated that while IFA models the two attributes 'extension' and 'metadata' as "Not Specified", there is nothing to say that an implementation could not define them as key value pair. YANG cannot have a attribute that is of type 'empty'. The question therefore the WG (which I forgot to ask) is that can SOL006 define them as KVP. Keeping the bug open to record that response and any action that might come out of it. |
modifiableAttributes in Vnfd is defined as 0..1 container, container two attributes 'extension' and 'metadata' each with a cardinality of 0..N. It is not clear how these attributes are expected to be used. What that means is data stored would look like { "extensions": { "cba", "abc", "foo", "bar", "xxx", "yyy" } } { "metadata": { "aaa", "bbb", "ccc", "ddd" } } Even if one were to know what "cba" extension means, there is no metadata associated with it. And one cannot assume that "aaa" is metadata for "cba" extension (at least in YANG, which can reorder data within extension and metadata). A much more sensible structure would be to have extension/metadata as key/value pair.