Page History

Andy Mayer

Amir Levy

Andrei Kojukhov

Michela Bevilacqua

Xu Yang

Lingli Deng

Yufei ZHou

han yanan

Alexander Vul

xinhuili

Brian Hedstrom

Fernando Oliveira

All the listed attributes (for simplicity).

Brian Hedstrom: The link provided above for Key-Value Pair Registries.docx, for the HPA Key Value Pairs, is linking to an OLD version of the file. The vduComputeRequirements Registry Example provided in the link above DOES NOT MATCH the vduComputeRequirements Registry Example provided in NFVIFA(18)000162r1. It's not clear to me if we are voting on the attributes only in this attribute table, or also voting on supporting the key value pairs per NFVIFA(18)000162r1. I would suggest the key value pairs be a separate poll/discussion. My vote here is for the attribute table only.

Xu Yang: to Brian, the vote is only for the attribute table, not the key value pairs.

maopeng zhang:

I agree HPA requirements.

1. All changes for HPA in R2 should not effect R1 VoLTE case.  It needs the data model compatible, which the VoLTE case already used. If this can be pre-condition in R2, I agree with add HPA attributes. But how to add, we needs more details.
   
2. The main purpose of OPT2 is to avoid redundancy parametes.
   Needs more KVP details and data model definitions to clear the solution benefits.

Michela Bevilacqua: updated version of the key value pairs registry to be supported in R2 and identification of deprecated (legacy) attributes to be finalised.

Thinh Nguyenphu: With Option 1 or Option 2, there is a way in TOSCA grammar to indicate the status of each TOSCA properties (supported, unsupported, experimental, deprecated). Thus, we can indicate to implementer how some of these duplicate attributes status. Of course Option 2 is possible, it would requires these supporting companies to bring concrete CRs to remove these duplicate attributes, as soon as possible. It is not good practice to remove an attribute(s) once a specification is already published without early notification.

Brian Hedstrom I support deprecating or obsoleting the hardcoded legacy attributes in favor of the key-value pairs. I don't think they should be deleted from the DM in order to support backward compatibility (and make them optional), but they should be deprecated or obsoleted so they are not used going forward.

Xu Yang: Possible redundant attributes: numVirtualCpu, virtualCpuClock, logicalCpuPinningPolicy, logicalCpuThreadPinningPolicy

Alexander Vul: the computeRequirements attribute is not HPA related.

Xu Yang: remove computeRequirements

Alexander Vul: These are not redundant. If I remember right, they are complementary...

Srinivasa Addepalli : Same comment as above.  Since we have 'requestAdditonalCapability' IE for any advanced attributes, I prefer we remove 'vduMemRequirements' element from the 'virtualMemoryData' to avoid any confusion.

Xu Yang: Question: In the example document, the logical node requirements are categorized into compute, memory and network categories. But in IFA011, only one logicalNode attribute is defined, what's the mapping here?Srinivasa Addepalli :  Based on explanation in IFA011, it appears to me that one use case for this is to specify NUMA nodes.  I feel that NUMA can be specified in 'requestAdditionalCapability'.  So, personally, I feel that this term is confusing and would like to see any advanced capability requirements to be pushed to 'requestAddtionalCapability', which is generic to represent feature requirements.  Alexander Vul has final say from Intel side 

Alexander Vul: There is a single k/v array holding attributes from three registries... We will optimize this, when registries are created.

Brian Hedstrom Is logicalNode and logicalNodeDescr the same attribute? I'm finding both in the Wiki. logicalNode is not listed as an attribute for Class: VirtualComputeDesc

Xu Yang: Question: related to the above comment, if the network logical node requirements are specific, should this be a dedicated data type instead of a reference?

Srinivasa Addepalli:  I have related question. Why is this reference? Is it meant to represent 'virtio','pci-passthrough' and 'sriov nic' kind of information?  In any case, few examples would be good.

Alexander Vul: Hmm... Need to think about it. As I review both the NFV Profile based spec and the SOL spec, I am finding some oddities.. We may have a mistake or two in how things got modeled..

Brian Hedstrom nicloRequirements is not listed as an attribute (or data type for other attribute) for Class: VirtualNetworkInterfaceRequirements

Brian Hedstrom This appears to be a Class, not an attribute.