[datamodel-upd][SOL002][VNF-LCM][v5.2.1][6.3.5.x.x Test-IDs] Change... (8a9db06a) · Commits · NFV - Network Functions Virtualisation / api-tests

SOL002/VNFLifecycleManagement-API/schemas/VnfSnapshotInfo.schema.json

+6 −6

Original line number	Diff line number	Diff line
		@@ -1948,7 +1948,7 @@
		}
		},
		"extManagedVirtualLinkInfo": {
		"description": "Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n",
		"description": "This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that \n a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n",
		"type": "array",
		"items": {
		"description": "This type provides information about an externally-managed virtual link.\n",
		@@ -2019,7 +2019,7 @@
		}
		},
		"vnfLinkPorts": {
		"description": "Link ports of this VL.\n",
		"description": "Link ports of this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId\n with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId\n and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\"\n attribute.\n",
		@@ -2104,7 +2104,7 @@
		}
		},
		"vnfNetAttDefResource": {
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n",
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n",

SOL002/VNFLifecycleManagement-API/schemas/VnfSnapshotsInfo.schema.json

+25 −26

Original line number	Diff line number	Diff line
		@@ -1341,7 +1341,6 @@
		"type": "string"
		}
		}

		}
		}
		},
		@@ -1950,7 +1949,7 @@
		}
		},
		"extManagedVirtualLinkInfo": {
		"description": "Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n",
		"description": "This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that \n a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n",
		"type": "array",
		"items": {
		"description": "This type provides information about an externally-managed virtual link.\n",
		@@ -2021,7 +2020,7 @@
		}
		},
		"vnfLinkPorts": {
		"description": "Link ports of this VL.\n",
		"description": "Link ports of this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId\n with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId\n and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\"\n attribute.\n",
		@@ -2106,7 +2105,7 @@
		}
		},
		"vnfNetAttDefResource": {
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n",
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n",

SOL002/VNFLifecycleManagement-API/schemas/vnfInstance.schema.json

+3 −3

Original line number	Diff line number	Diff line
		@@ -1893,7 +1893,7 @@
		}
		},
		"extManagedVirtualLinkInfo": {
		"description": "Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n",
		"description": "This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that \n a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n",
		"type": "array",
		"items": {
		"description": "This type provides information about an externally-managed virtual link.\n",
		@@ -1964,7 +1964,7 @@
		}
		},
		"vnfLinkPorts": {
		"description": "Link ports of this VL.\n",
		"description": "Link ports of this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId\n with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId\n and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\"\n attribute.\n",
		@@ -2049,7 +2049,7 @@
		}
		},
		"vnfNetAttDefResource": {
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n",
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n",

SOL002/VNFLifecycleManagement-API/schemas/vnfInstances.schema.json

+4 −4

Original line number	Diff line number	Diff line
		@@ -1895,7 +1895,7 @@
		}
		},
		"extManagedVirtualLinkInfo": {
		"description": "Information about the externally managed internal VLs of the VNF instance. See note 5 and note 6. It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 5.5.3.5). Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be listed in the \"vnfVirtualLinkResourceInfo\" attribute as this would be redundant.\n",
		"description": "This type provides information about an externally-managed virtual link. *NOTE: Both vnfLinkPort and vnfNetAttDefResource can be present in an ExtManagedVirtualLinkInfo to indicate that \n a single internal virtual link is providing connectivity for both VM-based and container-based VNFCs.\n",
		"type": "array",
		"items": {
		"description": "This type provides information about an externally-managed virtual link.\n",
		@@ -1966,7 +1966,7 @@
		}
		},
		"vnfLinkPorts": {
		"description": "Link ports of this VL.\n",
		"description": "Link ports of this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type represents a link port of an internal VL of a VNF.\nNOTE 1: Either cpInstanceId with cpInstanceType set to \"EXT_CP\" or any combination of cpInstanceId\n with cpInstanceType set to \"VNFC_CP\" and vipCpInstanceId (i.e. one or both of them) shall be \n present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to \"VNFC_CP\" \n and vipCpInstanceId are present, the two different CP instances share the linkport.\nNOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId\n and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or \n only vipCpInstanceId is present (UC6 and UC#6-b).\nNOTE 3: The value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\"\n attribute.\n",
		@@ -2051,7 +2051,7 @@
		}
		},
		"vnfNetAttDefResource": {
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL.\n",
		"description": "Network attachment definition resources that provide the specification of the interface to attach connection points to this VL. See note\n",
		"type": "array",
		"items": {
		"description": "This type contains information related to a network attachment definition resource that provides the specification of the interface used to connect one or multiple connection points to a secondary container cluster network.\n",