Re: [onap-discuss] [modeling] Data model mapping using SOL001
Thanks Thinh for your response. I think it is more of an issue than just naming conventions, and that we can't just take the SOL001 mappings "as defined": 1. You are saying that SOL001 shall not include postfixes of "d","D", "Desc", etc. So, why in one case they have "VNF", and another "VnfVirtualLinkDesc". Is the "VNF" mapping a "Vnf" or a "Vnfd"? They really should be EXPLICIT in the IFA elements they are mapping, and not just say they are leaving off this important postfix. 2. All of our IM classes are "descriptors". SOL001 sometimes maps descriptors to "nodes" (VNF, VDU, Cpd...), sometimes to "capabilities" (VirtualCompute... did they mean this as a descriptor or a resource?), and other times to "datatypes" (VirtualCpu, VirtualMemory,LogicalNode...). Don't we want them all to be "nodes"? 3. Regarding the mapping of "datatypes" mentioned above, I assume they did this because those entities are datatypes in the IFA model and not "descriptor" classes as we've made them in the ONAP model. We are not being consistent in our mapping. If we mean them to be descriptors, they should be "nodes" as well. -Jessie On Mon, Mar 5, 2018 at 1:13 PM, Nguyenphu, Thinh (Nokia - US/Irving) < thinh.nguyen...@nokia.com> wrote: > Hi Jessie, > > > > Your summary below shows there are a lot of inconsistency of TOSCA types > naming convention with IFA011. I fully acknowledge it. SOL WG is in the > process of cleaning it up with these guidelines: > >- SOL001 Type naming convention is UpperCamelCase. >- SOL001 properties naming convention is lowercase_underscored or >snake_case. >- SOL001 shall not include postfixes of “d”, “D”, “Desc”, “Descr” of >type or properties names. >- SOL001 shall not include prefixes of “vnf” of properties names, like >vnfdid, vnfProvider, vnfProductName, vnfSoftwareVersion, > vnfdVersion,vnfProductInfoName, >vnfProductinfoDescription. > > > > The inconsistence issues should be resolved with the next version of > SOL001 (v0.6.0). > > > > Meanwhile, I have created a wiki page to show all of the ONAP R2 Resource > IM attributes (clean version wiki page) map to SOL001 (TOSCA model) data > model, https://wiki.onap.org/pages/viewpage.action?pageId=25436710. (see > SOL001 Mapping column). The mapping table shows that all of ONAP Resource > IM attributes are mapped into TOSCA types with detail. Except for any of > new attributes (“orange” highlighted text) are not yet defined. > > > > Perhaps, I can introduce this page at Modeling sub_committee on Tuesday > call. > > > > Thinh > > > > *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@ > lists.onap.org] *On Behalf Of *jessie jewitt > *Sent:* Friday, March 02, 2018 1:20 PM > *To:* onap-discuss@lists.onap.org > *Subject:* [onap-discuss] [modeling] Data model mapping using SOL001 > > > > This message is particularly directed to Anatoly, Alex, and Thinh, as we > have an action item to map ONAP IM to DM. If one of you could respond, I'd > appreciate it. > > > > My understanding is that SOL001 is mapping the VNFD model to TOSCA. They > indicate they are mapping the ETSI NFV elements listed below into TOSCA > types (page 12). > > > > I'm not clear why they chose the elements they did, as they don't all > correspond to the VNFD model which is defined in the ETSI > "VnfTemplateModule" of the model. > > > > Also, the actual ETSI elements named do not correspond to exactly what is > defined in the model (they probably just got sloppy, but they should pay > attention to detail). > > > > Here's the list of the currently defined elements that they map > > 1. VNF - Shouldn't this be Vnfd? The Vnf is defined in the VnfModule > of the model. Also, the element is called Vnf and not VNF. > > 2. VDU - OK, but it should be Vdu, not VDU. > > 3. Cpd -Maybe ok? It is defined in the CommonTemplateModule as an > abstract class. You don't instantiate abstract classes, so you will never > have an instance. Do you have TOSCA types that represent abstract classes? > Also, they don't map other abstract classes such as VirtualLinkDesc, so why > map this one? > > 4. VduCpd - OK. This would contain all the attributes in Cpd, so again > I'm not sure why you need Cpd. > > 5. VnfVirtualLinkDesc - OK > > 6. VnfExtCpd - OK > > 7. Virtual Storage - Shouldn't this be VirtualStorageDesc? > > 8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to > distinguish it fr
Re: [onap-discuss] [modeling] Data model mapping using SOL001
Hi Jessie, Your summary below shows there are a lot of inconsistency of TOSCA types naming convention with IFA011. I fully acknowledge it. SOL WG is in the process of cleaning it up with these guidelines: * SOL001 Type naming convention is UpperCamelCase. * SOL001 properties naming convention is lowercase_underscored or snake_case. * SOL001 shall not include postfixes of “d”, “D”, “Desc”, “Descr” of type or properties names. * SOL001 shall not include prefixes of “vnf” of properties names, like vnfdid, vnfProvider, vnfProductName, vnfSoftwareVersion, vnfdVersion,vnfProductInfoName, vnfProductinfoDescription. The inconsistence issues should be resolved with the next version of SOL001 (v0.6.0). Meanwhile, I have created a wiki page to show all of the ONAP R2 Resource IM attributes (clean version wiki page) map to SOL001 (TOSCA model) data model, https://wiki.onap.org/pages/viewpage.action?pageId=25436710. (see SOL001 Mapping column). The mapping table shows that all of ONAP Resource IM attributes are mapped into TOSCA types with detail. Except for any of new attributes (“orange” highlighted text) are not yet defined. Perhaps, I can introduce this page at Modeling sub_committee on Tuesday call. Thinh From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of jessie jewitt Sent: Friday, March 02, 2018 1:20 PM To: onap-discuss@lists.onap.org Subject: [onap-discuss] [modeling] Data model mapping using SOL001 This message is particularly directed to Anatoly, Alex, and Thinh, as we have an action item to map ONAP IM to DM. If one of you could respond, I'd appreciate it. My understanding is that SOL001 is mapping the VNFD model to TOSCA. They indicate they are mapping the ETSI NFV elements listed below into TOSCA types (page 12). I'm not clear why they chose the elements they did, as they don't all correspond to the VNFD model which is defined in the ETSI "VnfTemplateModule" of the model. Also, the actual ETSI elements named do not correspond to exactly what is defined in the model (they probably just got sloppy, but they should pay attention to detail). Here's the list of the currently defined elements that they map 1. VNF - Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of the model. Also, the element is called Vnf and not VNF. 2. VDU - OK, but it should be Vdu, not VDU. 3. Cpd -Maybe ok? It is defined in the CommonTemplateModule as an abstract class. You don't instantiate abstract classes, so you will never have an instance. Do you have TOSCA types that represent abstract classes? Also, they don't map other abstract classes such as VirtualLinkDesc, so why map this one? 4. VduCpd - OK. This would contain all the attributes in Cpd, so again I'm not sure why you need Cpd. 5. VnfVirtualLinkDesc - OK 6. VnfExtCpd - OK 7. Virtual Storage - Shouldn't this be VirtualStorageDesc? 8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to distinguish it from the VirtualCompute class. 9. Software Image - Shouldn't this be SwImageDesc? Particularly to distinguish it from SwImage. 10. Deployment Flavour - Shouldn't this be VnfDf? 11. Scaling Aspect - They should at least give the correct element name of ScalingAspect. 12. Element Group - I assume they mean VnfdElementGroup? They should use the correct name. 13. Instantiation Level - OK, but they should give the correct name InstantiationLevel. The names used in the Tosca types should be an exact reflection of the ETSI NFV element names as defined above. This is not always the case. For example, they use "VirtualCompute" instead of "VirtualComputeDesc". As we made changes in ONAP to ETSI class names, are we considering making changes to TOSCA type names to ensure adherence to the actual element names. Or do we want to change them to match ONAP names? For example, should tosca.nodes.nfv.Cpd be tosca.nodes.nfv.CPDesc? Also, they don't appear to map the all the classes that are defined in the VNFD model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc. Why? Thank you for your help, Jessie ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [modeling] Data model mapping using SOL001
This message is particularly directed to Anatoly, Alex, and Thinh, as we have an action item to map ONAP IM to DM. If one of you could respond, I'd appreciate it. My understanding is that SOL001 is mapping the VNFD model to TOSCA. They indicate they are mapping the ETSI NFV elements listed below into TOSCA types (page 12). I'm not clear why they chose the elements they did, as they don't all correspond to the VNFD model which is defined in the ETSI "VnfTemplateModule" of the model. Also, the actual ETSI elements named do not correspond to exactly what is defined in the model (they probably just got sloppy, but they should pay attention to detail). Here's the list of the currently defined elements that they map 1. VNF - Shouldn't this be Vnfd? The Vnf is defined in the VnfModule of the model. Also, the element is called Vnf and not VNF. 2. VDU - OK, but it should be Vdu, not VDU. 3. Cpd -Maybe ok? It is defined in the CommonTemplateModule as an abstract class. You don't instantiate abstract classes, so you will never have an instance. Do you have TOSCA types that represent abstract classes? Also, they don't map other abstract classes such as VirtualLinkDesc, so why map this one? 4. VduCpd - OK. This would contain all the attributes in Cpd, so again I'm not sure why you need Cpd. 5. VnfVirtualLinkDesc - OK 6. VnfExtCpd - OK 7. Virtual Storage - Shouldn't this be VirtualStorageDesc? 8. Virtual Compute - Shouldn't this be VirtualComputeDesc? Particularly to distinguish it from the VirtualCompute class. 9. Software Image - Shouldn't this be SwImageDesc? Particularly to distinguish it from SwImage. 10. Deployment Flavour - Shouldn't this be VnfDf? 11. Scaling Aspect - They should at least give the correct element name of ScalingAspect. 12. Element Group - I assume they mean VnfdElementGroup? They should use the correct name. 13. Instantiation Level - OK, but they should give the correct name InstantiationLevel. The names used in the Tosca types should be an exact reflection of the ETSI NFV element names as defined above. This is not always the case. For example, they use "VirtualCompute" instead of "VirtualComputeDesc". As we made changes in ONAP to ETSI class names, are we considering making changes to TOSCA type names to ensure adherence to the actual element names. Or do we want to change them to match ONAP names? For example, should tosca.nodes.nfv.Cpd be tosca.nodes.nfv.CPDesc? Also, they don't appear to map the all the classes that are defined in the VNFD model, such as VirtualNetworkInterfaceRequirements, VnfIndicator, etc. Why? Thank you for your help, Jessie ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
