...
| 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) | |
| 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) | |
| 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) | |
| 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) | |
| 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) | |
| 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 ! | |
| 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! | |
| 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 ! |
| 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 latecncy, high throughput | missing | ||
| 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 |
| 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 |
| 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) | |
| 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 ? | |||
| 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 ! | |||
| 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 |
VIM Requirements (RA-1 Section 2.3.3)
| Ref# | RA-1 Sub-Category | Description | RA-1 Traceability | RI Applicable | RI Toolset | RI Notes | RC Category | RC Toolset | RC Notes | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | req.vim.01 | General | The Architecture must allow infrastructure resource sharing. | RA-1 3.2. "Consumable Infrastructure Resources and Services" | No | NA | OpenStack intrinsic | Functional | Functest | |
| 2 |
move to Recommendations | General | The Architecture should support deployment of OpenStack components in containers. | RA-1 4.3.2. "Containerised OpenStack Services" | Yes | Armada Chart | Functional | Functest | ||
| 3 | req.vim.03 | General | The Architecture must allow VIM to discover and manage Cloud Infrastructure resources. | RA-1 5.2.7. "Placement" | No | NA | OpenStack and IPMI | Functional | Functest | |
| 4 | req.vim.05 | General | The Architecture must include image repository management. | RA-1 4.3.1.2. "Glance" | No | NA | Image Service (Glance) (installed as part of OpenStack core services) | Functional | Functest | |
| 5 | req.vim.07 | General | The Architecture must support multi-tenancy. | RA-1 3.2.1. "Multi-Tenancy" | No | NA | OpenStack intrinsic | Functional | Functest | |
| 6 | req.vim.08 | General | The Architecture must support resource tagging. | "OpenStack Resource Tags" | No | NA | OpenStack resource metadata, neutron plugin | Functional | Functest |
...
| Ref# | RA-1 Sub-Category | Description | RA-1 Traceability | RI Applicable | RI Toolset | RI Notes | RC Category | RC Toolset | RC Notes | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | req.int.api.01 | API | The Architecture must provide APIs to access all mandatory features of the cloud platform core services for the given CNTT OpenStack release. | RA-1 5.3. "Consolidated Set of APIs" | No | NA | OpenStack APIs | Functional | Functest | |
| 2 | req.int.api.02 | API | The Architecture must provide GUI access to tenant facing cloud platform core services. | RA-1 4.3.1.9 "Horizon" | No | NA | Horizon (installed as part of OpenStack core services) | Functional | Functest | |
| 3 | req.int.api.03 | API | The Architecture must provide APIs needed to discover and manage Cloud Infrastructure resources. | RA-1 5.2.7. "Placement" | No | NA | OpenStack API | Functional | Functest | |
| 4 | req.int.api.04 | API | The Architecture must expose the latest version and microversion of the APIs for the given CNTT OpenStack release for each of the OpenStack core services | RA-1 5.2 Core OpenStack Services APIs | No | NA | OpenStack APIs for deployment manifests should include the details | Functional | ||
| 5 |
move to Recommendations | Acceleration | The Architecture should provide an open and standard acceleration interface to VNFs. | RA-1 2.3.4. (was RA-1 5.3.4 - "Cyborg") | No | NA | Acceleration Service (Cyborg) for deployment manifests should include the details | Functional | Functest |
Tenant Requirements (RA-1 Section 2.3.5)
...