...
| Ref# | RA-1 Sub-Category | Description | RA-1 Traceability | RI Applicable | RI Toolset | RI Notes | RC Category | RC Toolset | RC Notes | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | req.gen.ost.01 | Open source | The Architecture must use OpenStack APIs. | RA-1 5.3. Consolidated Set of APIs | Yes | Armada Chart | with Airship 2.0 will replace with helm operator | Functional | ||
| 2 | req.gen.ost.02 | Open source | The Architecture must support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs. | RA-1 5.3. Consolidated Set of APIs | Yes | NA | Once OpenStack installed this is intrinsic capability | Functional | ||
| 3 | req.gen.rsl.01 | Resiliency | The Architecture must support resilient OpenStack components that are required for the continued availability of running workloads. | RA-1 3.3.1. VIM Core services | Yes | NA | Once k8s installed this is intrinsic capability | OSTK components resiliency | supported through redundancy; redundancy and recoverability can be managed through k8s | |
| 4 | req.gen.avl.01 | Availability | The Architecture must provide High Availability for OpenStack components. | RA-1 4.2 Underlying Resources | Yes | NA | Once k8s installed this is intrinsic capability | OSTK Components High Availability | missing Al Morton There are several HA tests conducted as part of OVP 1.0, are they sufficient? | supported through redundancy; redundancy and recoverability can be managed through k8s |
...
| Ref# | RA-1 Sub-Category | Description | RA-1 Traceability | RI Applicable | RI Toolset | RI Notes | RC Category | RC Toolset | RC Notes | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | req.inf.com.01 | Compute | The Architecture must provide compute resources for VM instances. | RA-1 3.3.1.4 "Cloud Workload Services" | Yes | Armada Chart | Functional | Functest | ||
| 2 | req.inf.com.04 | Compute | The Architecture must be able to support multiple CPU SKU options to support various infrastructure profiles (Base, and Network Intensive). | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" | Yes | Armada Chart | Post processing | Functional | missing | needs to be confirmed (same as RM requirements) |
| 3 | req.inf.com.05 | Compute | The Architecture must support Hardware Platforms with NUMA capabilities. | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" | Yes | Armada Chart | Functional | Functest | Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) comment acknowledged, no action required | |
| 4 | req.inf.com.06 | Compute | The Architecture must support CPU Pinning of the vCPUs of VM instance. | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" | Yes | Armada Chart | Functional | Functest | Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) comment acknowledged, no action required | |
| 5 | req.inf.com.07 | Compute | The Architecture must support different hardware configurations to support various infrastructure profiles (Base, and Network Intensive). | RA-1 3.3.3. "Host aggregates providing resource pooling" | Yes | Armada chart | Functional | Functest | Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) comment acknowledged, no action required | |
| 6 | req.inf.com.08 | Compute | The Architecture must support allocating certain number of host cores/threads to non-tenant workloads such as for OpenStack services. | Dedicating host core/sibling threads to certain workloads (e.g., OpenStack services. Please see example, "Configuring libvirt compute nodes for CPU pinning" | Yes | Armada chart | Functional | |||
| 7 | req.inf.com.09 | Compute | The Architecture must ensure that the host cores/threads assigned to a workload are thread-sibling aware: that is, that a core and its associated SMT threads are either all assigned to non-tenant workloads or all assigned to tenant workloads. | Achieved through configuring the "cpu_dedicated_set" and "cpu_shared_set" parameters in nova.conf correctly. | Yes | Armada chart | Functional | |||
| 8 | req.inf.stg.01 | Storage | The Architecture must provide remote (not directly attached to the host) Block storage for VM Instances. | RA-1 3.4.2.3. "Storage" | Yes | Armada chart | Functional | Functest | too generic and should mention the ref to the mandatory capabilities and the status expected. 130 single tests about volumes amongst tempest_cinder, tempest_full, tempest_scenario and tempest_slow ( +indirect testing in case of tempest_heat) addressed in req.int.api.03 below (PR #1622 merged) | |
| 9 | req.inf.stg.02 | Storage | The Architecture must provide Object storage for VM Instances. Operators may choose not to implement Object Storage but must be cognizant of the risk of "Compliant VNFs" failing in their environment. | OpenStack Swift Service (RA-1 4.3.1.4 "Swift") | Yes | Armada chart | Functional | Functest | too generic and should mention the ref to the mandatory capabilities and the status expected. 140 single tests about object storage amongst tempest_full, tempest_scenario and tempest_slow ( +indirect testing in case of tempest_heat) addressed in req.int.api.04 below (PR #1622 merged) | |
| 10 |
move to Recommendations | Storage | The Architecture may provide a file system service (file system storage solution) for VM Instances. | RA-1 4.2.4. "Storage Backend" | Yes | Armada chart | Functional | Out of CNTT RC (may) + an API proposing this feature should be proposed in CNTT first | The tempest plugin could be added in Functest if it makes sens (IaaS verification). Useless on CNTT side right now Bug here! | |
| 11 |
move to Recommendations | Storage | The Architecture may support Software Defined Storage (SDS) that seamlessly supports shared block storage, object storage and flat files. | RA-1 4.2.4.1. "Ceph Storage Cluster" | Yes | Armada chart | Functional | Out of CNTT RC (may) | As far as I understand It's out of CNTT (implementation design) Ceph is tested thought the mandatory service API by Functest | |
| 12 |
move to Recommendations | Storage | The Architecture should make the immutable images available via location independent means. | RA-1 4.3.1.2. "Glance" | Yes | Armada chart | Functional | Functest | It's a must requirement according RA1 Chapter5 Bug here ! Glance is required but not necessarily immutable images – some operators make changes to install needed tools such anti-virus etc. | |
| 13 |
move to Recommendations | Storage | The Architecture should provide high-performance and horizontally scalable VM storage. | RA-1 4.2.4.1. "Ceph Storage Cluster" | Yes | Armada chart | Functional | Functest | As far as I understand It's out of CNTT (implementation design) and the related API is a must requirement. Does it make sens to cover ceph from a functional pov (why not benchmarking)? Bug here! ceph is not required – during requirement creation there was opposition | |
| 14 |
this reqt is for local, move to Recommendations | Storage | The Architecture should provide local Block storage for VM Instances. | RA-1 "Virtual Storage" | Yes | Armada chart | Functional | Functest | ||
| 15 |
move to Recommendations | Storage | The Architecture should support the Block storage capabilities specified in https://docs.openstack.org/api-ref/block-storage/. | RA-1 5.2.3. "Cinder" | No | NA | Cinder is the Block storage Service | Functional | Functest | It's a must requirement according RA1 Chapter5 Bug here ! The original reuirement is to support all Cinder capabilities listed in the refererred to document – and that is not rquired only some features are required |
| 16 | req.inf.ntw.01 | Network | The Architecture must provide virtual network interfaces to VM instances. | RA-1 5.2.5. "Neutron" | No | NA | Neutron | Functional | Functest | |
| 17 | req.inf.ntw.02 | Network | The Architecture must include capabilities for integrating SDN controllers to support provisioning of network services, from the OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs. | RA-1 3.2.5. "Virtual Networking – 3rd party SDN solution" | Yes | Functional | Functest | |||
| 18 | req.inf.ntw.03 | Network | The Architecture must support low latency and high throughput traffic needs. | RA-1 4.2.3. "Network Fabric" | No | NA | low latecncylatency, high throughput | missing VSPERF BM Tests: p2p and pvp Cloud tests possible with PROX and NFVBench | Al Morton updated: Tests Desc: ETSI NFV TST009, clauses 8 and 9 | |
| 19 | req.inf.ntw.05 | Network | The Architecture must allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve). | RA-1 4.2.3. "Network Fabric" | Yes | Functional | Functest | |||
| 20 | req.inf.ntw.07 | Network | The Architecture must support network resiliency. | RA-1 3.4.2.2. "Network" | No | NA | may be achieved through redundancy | network resiliency | missing | may be achieved through redundancy Al Morton Need the Leaf-Spine switch configurations (not typically in OPNFV Pods). |
| 21 | req.inf.ntw.10 | Network | The Cloud Infrastructure Network Fabric must be capable of enabling highly available (Five 9’s or better) Cloud Infrastructure. | RA-1 3.4.2.2. "Network" | No | NA | may be achieved through redundancy | network availability | missing | may be achieved through redundancy Al Morton 5-9's Not Testable in reasonable time frames. 5 Nines = 53 minutes downtime PER YEAR, average |
| 22 | req.inf.ntw.15 | Network | The Architecture must support multiple networking options for Cloud Infrastructure to support various infrastructure profiles (Basic Network Intensive). | RA-1 4.2.3.4. "Neutron ML2-plugin Integration" and "OpenStack Neutron Plugins" | Yes | Armada chart | Functional | Functest | As far as I understand It's out of CNTT (implementation design). RA1 Chapter5 sets as mandatory the networking capabilities (already verified by neutron agents and OVN) This requirement is about the support of network options such as SDN through the use of plugins. req.int.api.05 below (PR #1622 merged) deals with your comment about mandatory capabilities | |
| 23 | req.inf.ntw.16 | Network | The Architecture must support dual stack IPv4 and IPv6 for tenant networks and workloads. | No | NA | Functional | Functest | |||
| 24 |
move to Recommendations | Network | The Architecture should use dual stack IPv4 and IPv6 for Cloud Infrastructure internal networks. | Yes | Functional | Functest | Must be clarified. Endpoints are registered by IPv4 or IPv6. Bug ? THis is not about APIs but the use of dual stack in Controller nodes | |||
| 25 | req.inf.ntw.18 | Network | The Architecture should support the network extensions specified in https://docs.openstack.org/api-ref/network/v2/. | RA-1 5.2.5. "Neutron" | Armada chart | Functional | It's a must requirement according RA1 Chapter5 Bug here ! Not all network extensions are mandatory – the mandatory are now covered under req.int.api.05 | |||
| 26 |
move to Recommendations keep for Baraque | Acceleration | The Architecture should support Application Specific Acceleration (exposed to VNFs). | RA-1 3.2.6. "Acceleration" and RA-1 4.3.1.10. "Cyborg" | Armada chart | Functional | Out of CNTT RC (should) + an API proposing this feature should be proposed in CNTT RA1 first | |||
| 27 |
move to Recommendations keep for Baraque | Acceleration | The Architecture should support Cloud Infrastructure Acceleration (such as SmartNICs). | "OpenStack Future - Specs defined" | Armada chart | Functional | Out of CNTT RC (should) + an API proposing this feature should be proposed in CNTT RA1 first |
...