Page tree
Skip to end of metadata
Go to start of metadata


This version of the RA-1 Requirements Table includes the RWG assessment in the following areas (see slide 8 of 2020 Release Process):

  1. Is the requirement actionable?
  2. Is the requirement In-Scope for OPNFV? (YES unless noted)
  3. Is the requirement Technologically Feasible (and clearly testable or verifiable through automated means) ?
  4. Is the requirement prioritized for JERMA Release?

The Tables on this page are copied from the RA-1 requirements wiki (RA-1, RI-1 and RC-1 Traceability and Gap Analysis) as of . Note that the RI applicability column was  redundant with RI Tool set column, and that column was replaced by the RWG Assessment information.

This page is WORK IN PROGRESS   The current inital assessment stops at the Security requirements, on .

General Requirements (RA-1 Section 2.3.1)



Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.gen.ost.01Open sourceThe Architecture must use OpenStack APIs.RA-1 5.3. Consolidated Set of APIs

Very General wording, covered under many other requirements, and made more precise in other requirements (Baldy)

Could be deleted (replace with 6 new requirments in Baldy, one requirment per mandatory OS service)

Actionable: (currently expressed as multiple requirements in Baldy)
Feasible: yes
JERMA: yes Cedric Ollivier : already delivered and updated according to CNTT Baraque:

Cedric Ollivier Functest supports CNTT from Hunter and all branches are synchronized including Kali and master. Nothing specific to Jerma

Actions:  Requirement replaced & listed in RA1 2.3.4 https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter02.md#234-interfaces--apis-requirements

Armada Chart

Manifests

with Airship 2.0 will replace with helm operator

Functional

Functest - many cases cover this.

CNTT RC-1 Chapter 2 or 3, test cases selected according to RA-1 Ch 5.


2req.gen.ost.02Open sourceThe Architecture must support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs.RA-1 5.3. Consolidated Set of APIs

Very General wording, covered under many other requirements.

JERMA -

Action: Requirement replaced & listed in 2.3.2 Infrastructure Requirements https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter02.md#232-infrastructure-requirements

NAOnce OpenStack installed this is intrinsic capability

Functional


Is this supported in Functest?  Do RC-1 tests take care of this?
3req.gen.rsl.01ResiliencyThe Architecture must support resilient OpenStack components that are required for the continued availability of running workloads.RA-1 3.3.1. VIM Core services

Q: Why is K8s mentioned in the notes??

See RA-1 ch4 4.3.2. Containerised OpenStack Services https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter04.md#432-containerised-openstack-services

See RC Toolset comments

Should not be done in Production, this is destructive testing. YS tests were intended for pre-production.

Actionable: yes/no
Feasible: yes/no
JERMA: yes/no

ACTIONS:

Need more info on HOW we deploy and test.

Consider if API shutdown solution will work in general. Shut-down of agents may have side effects.

NAOnce k8s installed this is intrinsic capabilityOSTK components resiliency

missing

Al Morton There are several HA tests conducted as part of OVP 1.0, are they sufficient?

Yardstick TC025 and/or TC045

supported through redundancy; redundancy and recoverability can be managed through k8s


4req.gen.avl.01Availability

The Architecture must provide High Availability for OpenStack components.

(where High Availability means a percentage of time, different from evaluation of resiliency)

RA-1 4.2 Underlying Resources

Q: Why is K8s mentioned in the notes??  See above.

See RC Toolset comments

NAOnce k8s installed this is intrinsic capabilityOSTK 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

Infrastructure Requirements (RA-1 Section 2.3.2)

RELREQ-13 - Getting issue details... STATUS


Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.inf.com.01ComputeThe Architecture must provide compute resources for VM instances.RA-1 3.3.1.4 "Cloud Workload Services"

Very General wording, covered under many other requirements.

JERMA - AIRSHIP

Armada Chart

Functional

Functest
2req.inf.com.04ComputeThe 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"

Not clear, possibly not actionable.

Req. references installation flavors


Armada Chart


Sept 25 - requirement lacks clarity. Need more detail.

Post-installation processingFunctionalmissingneeds to be confirmed (same as RM requirements)
3req.inf.com.05ComputeThe Architecture must support Hardware Platforms with NUMA capabilities.RA-1 4.4.1. "Support for Profiles and T-shirt instance types"

Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

JERMA- AIRSHIP & Functest


Armada Chart

Sept 25 - Enabling NUMA is already supported by Airship.


FunctionalFunctest

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

4req.inf.com.06ComputeThe Architecture must support CPU Pinning of the vCPUs of VM instance.RA-1 4.4.1. "Support for Profiles and T-shirt instance types"

Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Note that some OPNFV tests can perform automated tests using CPU pinning (VSPERF).

Sept 25 - requirement is already supported.


Armada Chart
FunctionalFunctest

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

5req.inf.com.07ComputeThe 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"


Reference for profiles: RM Chapter 5 (https://github.com/cntt-n/CNTT/blob/master/doc/ref_model/chapters/chapter05.md)

Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

JERMA - AIRSHIP

Sept 25 - Airship supports minimum system configuration using OpenStack, as identified in RA specification. No action necessary for this requirement.

Armada chartAIRSHIP supportsFunctionalFunctest

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

6req.inf.com.08ComputeThe 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"

No RA-1 section.

Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Armada chartAIRSHIP Supports in general, it sets aside the cores and installs the guest operating systems there. (Sept 25)
Functional

7req.inf.com.09ComputeThe 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.


No RA-1 section.

Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

See RC comments.

HOW this requirement is implemented will be very different depending on the installer, and therefore an installation-agnostic verification of VM instantiation is needed.

Armada chart


Need to confirm the above: how to configure in AIRSHIP.  Where in the charts and What needs to be set.

This is beyond OpenStack, config of HW, config of SW


Functional

Need to verify ability to configure, and the ability to confirm (with "show-like" commands) whether the config has been achieved - No way to automate such a test.


Testing or verification development is limited to Installers available to OPNFV.

Possibly use virsh command for KVM, or libvirt, or Nova CLI or API.

Al Morton Possibly verified with VSPERF testing (Cross-NUMA Test Results). Also ETSI NFV TST009, clause 12.4 and Annex D.

David McBride to contact Sridhar for input.

8req.inf.stg.01StorageThe Architecture must provide remote (not directly attached to the host) Block storage for VM Instances.RA-1 3.4.2.3. "Storage"

Very General wording, covered under many possible tests & requirements.

JERMA ??

See RC comments.

Update:  

Main sticking point is the ability to distinguish remote storage from local during testing.

Remains a must-level requirement for CNTT Baraque.

Armada chart


 

FunctionalFunctest

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)

9req.inf.stg.02StorageThe 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")

Very General wording, covered under many possible tests & requirements.

JERMA ??

See RC comments.

Update:  

OPNFV has not included Object storage  in previous tests (do we agree on this statement?)

Remains a must-level requirement for CNTT Baraque.

Armada chart
FunctionalFunctest

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

req.inf.stg.03


move to Recommendations

StorageThe Architecture may provide a file system service (file system storage solution) for VM Instances.RA-1 4.2.4. "Storage Backend"

Update:  

Remains may in Baldy and Baldy.1.

Removed in Baraque.

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

req.inf.stg.04

move to Recommendations

StorageThe 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"

Update:  

Remains may in Baldy and Baldy.1.

Removed in Baraque.

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

req.inf.stg.06

move to Recommendations

StorageThe Architecture should make the immutable images available via location independent means.RA-1 4.3.1.2. "Glance"

Update:  

Remains should in Baldy and Baldy.1 (superceeds RC note).

Removed in Baraque.

Armada chart
FunctionalFunctest

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

req.inf.stg.07

move to Recommendations

StorageThe Architecture should provide high-performance and horizontally scalable VM storage.RA-1 4.2.4.1. "Ceph Storage Cluster"

Update:  

Remains should in Baldy and Baldy.1.

Removed in Baraque.

Armada chart
FunctionalFunctest

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

req.inf.stg.10

duplicate and wrong – modify

this reqt is for local, 

req.inf.stg.01  was for "remote"

move to Recommendations

StorageThe Architecture should provide local Block storage for VM Instances.RA-1 "Virtual Storage"

Update:  

Remains should in Baldy and Baldy.1.

Remains should in Baraque (despite note: "move to Recommendations")

Armada chart
FunctionalFunctest
15

req.inf.stg.11

duplicate and wrong - modify

move to Recommendations

StorageThe Architecture should support the Block storage capabilities specified in https://docs.openstack.org/api-ref/block-storage/.RA-1 5.2.3. "Cinder"

Update:  

Remains should in Baldy and Baldy.1 (superceeds RC note).

Removed in Baraque.

NACinder is the Block storage ServiceFunctionalFunctest

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

15a

req.inf.stg.08

THIS REQ was added in BALDY.1

StorageThe Architecture should allow use of externally provided large archival storage for its Backup

Update:  

THIS REQ was added in BALDY.1

OPNFV JERMA: Out of Scope

Appears in BARAQUE






15b

req.inf.stg.09

THIS REQ was added in BALDY.1

StorageThe Architecture should make available all non-host OS / Hypervisor / Host systems storage as network-based Block, File or Object Storage for tenant/management consumption.

Update:  

THIS REQ was added in BALDY.1

OPNFV JERMA: Out of Scope

Appears in BARAQUE






16req.inf.ntw.01NetworkThe Architecture must provide virtual network interfaces to VM instances.RA-1 5.2.5. "Neutron"

Very General wording, covered under many possible tests & requirements.

JERMA ??

NANeutronFunctionalFunctest
17req.inf.ntw.02NetworkThe 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"Very General wording, is the ACTION an Infrastructure Verification, a configuration feature test, or both?

FunctionalFunctest
18req.inf.ntw.03NetworkThe Architecture must support low latency and high throughput traffic needs.RA-1 4.2.3. "Network Fabric"Very General wording,

covered under many possible tests & requirements.

JERMA

See RC comments

Actionable: yes

Feasible: yes

JERMA: yes

VSPERF & Prox

NA
low latency, high throughput

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

Note: RA-1 reference is "content to be developed".

19req.inf.ntw.05NetworkThe 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"Very General wording,

is the ACTION an Infrastructure Verification, a configuration feature test, or both?

JERMA



FunctionalFunctest
20req.inf.ntw.07NetworkThe Architecture must support network resiliency.RA-1 3.4.2.2. "Network"Very General wording,

is the ACTION an Infrastructure Verification, a configuration feature test, or both?

JERMA

See RC Notes

Actionable: not currently possible for automated testing.

Feasible: no

JERMA: no


NAmay be achieved through redundancynetwork resiliencymissing

may be achieved through redundancy

Al Morton Need the Leaf-Spine switch configurations (not typically configured in OPNFV Pods).

Question: is this possible in OPNFV LaaS (active switch port shutdown for testing)?

21req.inf.ntw.10NetworkThe 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"

Very General wording.

Not in OPNFV SCOPE.

NOT ACTIONABLE or TESTABLE.

See RC Notes

Actionable: no

Feasible: no

JERMA: no

Scope: no

NAmay be achieved through redundancynetwork availabilityusually done with modeling

may be achieved through redundancy

Al Morton 5-9's Not Testable in reasonable time frames. 5 Nines = 53 minutes downtime PER YEAR, average

22req.inf.ntw.15NetworkThe 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"See RC commentsArmada chart
FunctionalFunctest

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

23req.inf.ntw.16NetworkThe Architecture must support dual stack IPv4 and IPv6 for tenant networks and workloads.

Test Case Availability?

Cedric Ollivier: yes it's part of Functest Hunter and newer

SCOPE: most OPNFV labs are built on v4

Cedric Ollivier : and? it's about the overlay not the underlay. It's verified vs all Functest SUTs (OPNFV labs)

NA
FunctionalFunctest

Cedric Ollivier  please follow up on coverage

Cedric Ollivier : yes it's included and verified since Functest Hunter

24

req.inf.ntw.17

move to Recommendations

NetworkThe Architecture should use dual stack IPv4 and IPv6 for Cloud Infrastructure internal networks.
Yes

FunctionalFunctest

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

25req.inf.ntw.18NetworkThe 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

req.inf.acc.01

move to Recommendations

keep for Baraque

AccelerationThe 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"Cyborg testing is part of Functest Kali and master."

Out of CNTT RC (should)

+ an API proposing this feature should be proposed in CNTT RA1 first

27

req.inf.acc.02

move to Recommendations

keep for Baraque

AccelerationThe 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-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.vim.01GeneralThe Architecture must allow infrastructure resource sharing.RA-1 3.2. "Consumable Infrastructure Resources and Services"Does Functest team agree with the CNTT status?NAOpenStack intrinsicFunctionalFunctest
2

req.vim.02

move to Recommendations

GeneralThe Architecture should support deployment of OpenStack components in containers.RA-1 4.3.2. "Containerised OpenStack Services"YesArmada Chart
FunctionalFunctest
3req.vim.03GeneralThe Architecture must allow VIM to discover and manage Cloud Infrastructure resources.RA-1 5.2.7. "Placement"Does Functest team agree with the CNTT status?NAOpenStack and IPMIFunctionalFunctest
4req.vim.05GeneralThe Architecture must include image repository management.RA-1 4.3.1.2. "Glance"Does Functest team agree with the CNTT status?NA

Image Service (Glance)

(installed as part of OpenStack core services)

FunctionalFunctest
5req.vim.07GeneralThe Architecture must support multi-tenancy.RA-1 3.2.1. "Multi-Tenancy"Does Functest team agree with the CNTT status?NAOpenStack intrinsicFunctionalFunctest
6req.vim.08GeneralThe Architecture must support resource tagging."OpenStack Resource Tags"Does Functest team agree with the CNTT status?NAOpenStack resource metadata, neutron pluginFunctionalFunctest

Interfaces & API Requirements (RA-1 Section 2.3.4)



Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.int.api.01APIThe Architecture must provide APIs to access to the authentication service and the associated mandatory features detailed in chapter 5.RA-1 5.2.1 "Keystone"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
2req.int.api.02APIThe Architecture must provide APIs to access to the image management service and the associated mandatory features detailed in chapter 5.RA-1 5.2.2 "Glance"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
3req.int.api.03APIThe Architecture must provide APIs to access to the block storage management service and the associated mandatory features detailed in chapter 5.RA-1 5.2.3 "Cinder"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
4req.int.api.04APIThe Architecture must provide APIs to access to the object storage management service and the associated mandatory features detailed in chapter 5.RA-1 5.2.4 "Swift"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
5req.int.api.05APIThe Architecture must provide APIs to access to the network management service and the associated mandatory features detailed in chapter 5.RA-1 5.2.5 "Neutron"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
6req.int.api.06APIThe Architecture must provide APIs to access to the compute resources management service and the associated mandatory features detailed in chapter 5.RA-1 5.2.6 "Nova"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
7req.int.api.07APIThe Architecture must provide GUI access to tenant facing cloud platform core services.RA-1 4.3.1.9 "Horizon"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
8req.int.api.08APIThe Architecture must provide APIs needed to discover and manage Cloud Infrastructure resources.RA-1 5.2.7. "Placement"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
9req.int.api.09APIThe Architecture must provide APIs to access to the orchestration service.RA-1 5.2.8 "Heat"Does Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
10req.int.api.10APIThe 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 APIsDoes Functest team agree with the CNTT status?NA

OpenStack APIs

for deployment manifests should include the details

FunctionalFunctest
11

req.int.acc.01

move to Recommendations

Accelerat.The Architecture should provide an open and standard acceleration interface to VNFs.RA-1 2.3.4. (was RA-1 5.3.4 - "Cyborg")NoNA

Acceleration Service (Cyborg)

for deployment manifests should include the details

Functional

Functest

"Cyborg testing is part of Functest Kali and master."


Tenant Requirements (RA-1 Section 2.3.5)



Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.tnt.gen.01GeneralThe Architecture must support multi-tenancy.duplicate of req.vim.07
NA



2req.tnt.gen.02GeneralThe Architecture must support self-service dashboard (GUI) and APIs for users to deploy, configure and manage their workloads.RA-1 4.3.1.9 "Horizon" and 3.3.1.4 Cloud Workload ServicesDoes Functest team agree with the CNTT status?NA

Horizon

(installed as part of OpenStack core services)

FunctionalFunctest

Operations & LCM Requirements (RA-1 Section 2.3.6)

RELREQ-17 - Getting issue details... STATUS


Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.lcm.gen.01GeneralThe Architecture must support zero downtime expansion/change of physical capacity (compute hosts, storage increase/replacement).

No RA-1 Tracebility

Is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Armada Chart

James Gu Discussion needed

Sept 25 - Airship relies on Kubernetes and Kubernetes supports this requirement already. No additional effort needed. If additional installers participate, may need to re-visit this requirement.

infra expansionmissing
2req.lcm.adp.02Automated deploymentThe Architecture must support hitless upgrades of software provided by the cloud provider so that the availability of running workloads is not impacted.

No RA-1 Tracebility

Is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Input: test is to monitor the worklloads to see impact, if any.

Actionable: yes/no

Feasible: yes/no

JERMA: yes/no

Armada Chart

internally will trigger k8s

James Gu Discussion needed

Sept 25 - See notes above.

software upgardes

missing

(Airship?)

Test traffic aspect to this test - further investigation

Assurance Requirements (RA-1 Section 2.3.7)

RELREQ-18 - Getting issue details... STATUS


Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRWG AssessmentRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.asr.mon.01IntegrationThe Architecture must include integration with various infrastructure components to support collection of telemetry for assurance monitoring and network intelligence.

No RA-1 Traceability

Is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Armada chartPrometheus & GrafanaFunctionalFunctest
2req.asr.mon.03MonitoringThe Architecture must allow for the collection and dissemination of performance and fault information.

No RA-1 Traceability

Is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Actionable: yes

Feasible: yes, to supply configurations

JERMA: yes/no

SCOPE:


Leave to operators HOW the data is collected,

THEN

Test: cause a node to fail and see if the alert is generated. Also Node loading.

ONAP DCAE does this form of testing - larger scale than OPNFV -



Armada chart

CollectD


Sept 25 - James to investigate Prometheus collector:

prometheus-alertmanager prometheus-blackbox-exporter prometheus-kube-state-metrics prometheus-node-exporter prometheus-openstack-exporter prometheus-process-exporter


performance/fault datamissing

Al Morton Barometer makes this info available, and VSPERF can collect telemetry while testing.

3req.asr.mon.04NetworkThe Cloud Infrastructure Network Fabric and Network Operating System must provide network operational visibility through alarming and streaming telemetry services for operational management, engineering planning, troubleshooting, and network performance optimisation.

No RA-1 Traceability

Is the ACTION an Infrastructure Verification, a configuration feature test, or both?

Additional details on Monitoring and Alerting in RA-1 CH 7

https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter07.md

Actual Metrics RM Ch 4:

https://github.com/cntt-n/CNTT/blob/master/doc/ref_model/chapters/chapter04.md

Also the ETSI references RM Ch4.

Requirement is Network-focused, but we have investigated telemetry beyond that scope.


Open Question: Will the Reference Implementation use Barometer to provide the required Network/other metrics? IOW, is this part of the RI?

If Yes, then the Barometer configuration to collect the required networking (OVS, DPDK, libvirt), storage (Ceph via collectd) and Compute /Infrastructure metrics is needed.

Some support for collecting metrics from VMs (libvirt). For specific VNFs, the vendor provides selected metrics and alerts. ONAP has DCAE for this purpose.

Ceilometer would collect the metrics for Openstack (not Barometer).

There are some perceived issues with Ceilometer, or Gnocci (default backend).

needs LMA platform installed

James Gu input required.


CollectD required by Barometer

telemetry

missing - alarming and reporting on barometer via prometheus already available via barometer work. Requirements not clear to find out whats needed of physical network

Emma Foley Uncertainty around the requirement.

Can barometer provide a configuration that allows the results to be collected, via colletcd or other?

Discussion is welcome in the weekly meeting or via this Jira ticket.

Security Requirements (RA-1 Section 2.3.8) | Needs to be updated with latest Security Requirements – CNTT declares these requirements under revision, therefore out-of-scope for JERMA

=============================================================================================================================

=============================================================================================================================

Security Requirements (RA-1 Section 2.3.8) | Needs to be updated with latest Security Requirements - CNTT declares these requirements under revision, therefore out-of-scope for JERMA


Ref#RA-1 Sub-CategoryDescriptionRA-1 TraceabilityRI ApplicableRI ToolsetRI NotesRC CategoryRC ToolsetRC Notes
1req.sec.gen.01GeneralThe Architecture must provide tenant isolation.
NoNAOpenStack intrinsicFunctionalFunctest
2req.sec.gen.02GeneralThe Architecture must support policy based RBAC.

6.3.1.4 RBAC

YesArmada Chart
FunctionalFunctest
3req.sec.gen.03GeneralThe Architecture must support a centralised authentication and authorisation mechanism.

6.3.1.2 Authentication and

6.3.1.3 Authorization

NoNA

Keystone

(installed as part of OpenStack core services)

FunctionalFunctest  
4req.sec.zon.01ZoningThe Architecture must support identity management (specific roles and permissions assigned to a domain or tenant).

6.3.1.1 Identity

NoNA

Keystone

(installed as part of OpenStack core services)

FunctionalFunctest
5req.sec.zon.02ZoningThe Architecture must support password encryption.
NoNA

Barbican

(installed as part of OpenStack core services)

FunctionalFunctest
6req.sec.zon.03ZoningThe Architecture must support data, at-rest and in-flight, encryption.6.3.3 Confidentiality and IntegrityYes

TLS 1.2+(in-flight)

at-rest use ceph default encryption

Functionalmissing
7req.sec.zon.04ZoningThe Architecture must support integration with Corporate Identity Management systems.
YesArmada chart
integrationmissing
8req.sec.cmp.02ComplianceThe Architecture must comply with all applicable standards and regulations.
NoNA
security standardsmissing in Functest. Captured in Telco TCs Security
9req.sec.cmp.03ComplianceThe Architecture must comply with all applicable regional standards and regulations.
NoNA
security standardsmissing
10req.sec.ntw.03NetworkingThe Architecture must have the underlay network incorporate encrypted and/or private communications channels to ensure its security.6.3.3.3 Confidentiality and Integrity of tenants DataNoNA
Functionalmissing
11req.sec.ntw.04NetworkingThe Architecture must configure all of the underlay network components to ensure the complete separation from the overlay customer deployments.

4.2.3.2 High Level Logical Network Layout

NoNA
network isolationmissing
12req.sec.ntw.05NetworkingThe Architecture must have the underlay network include strong access controls that adhere to the V1.1 NIST Cybersecurity Framework.6.3.1 Platform AccessNoNA
network access controlmissing

System Hardening (RA-1 Section 2.3.8.1)


 Ref #

 RA-1 Sub-Category

 Description

  RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

RC  Notes

1

 sec.gen.001

 Hardening

 The Platform must maintain the state to what it is specified to be and does not change unless through change management process.

7.2.2. Configuration Management

YesArmada chartArmada chart pushes the config to fix security

security hardening 



2

 sec.gen.002

 Hardening

 All systems part of Cloud Infrastructure must support password hardening (strength and rules for updates (process), storage and transmission, etc.)


Yes

security hardening



3

 sec.gen.003

 Hardening

 All servers part of Cloud Infrastructure must support a root of trust and secure boot

6.3.6 Security LCM  

Yes

security hardening  



4

 sec.gen.004

 Hardening

 The Operating Systems of all the servers part of Cloud Infrastructure must be hardened

6.3.2 System Hardening

Yes

security hardening  



5

 sec.gen.005

 Hardening

 The Platform must support Operating System level access control

6.3.1 Platform Access  

Yes

security hardening  



6

 sec.gen.006

 Hardening

 The Platform must support Secure logging

6.3.7 Security Audit Logging

Yes

security hardening  



7

 sec.gen.007

 Hardening

 All servers part of Cloud Infrastructure must be Time synchronized with authenticated Time service

  

YesArmada chart

security hardening  



8

 sec.gen.008

 Hardening

 All servers part of Cloud Infrastructure must be regularly updated to address security vulnerabilities

6.3.2 System Hardening  

Yes

security hardening  



9

 sec.gen.009

 Hardening

 The Platform must support Software integrity protection and verification

6.3.3 Confidentiality and Integrity  

No

security hardening  



10

 sec.gen.010

 Hardening

 The Cloud Infrastructure must support Secure storage (all types)

6.3.6 Security LCM

Yes

security hardening  



11

 sec.gen.012

 Hardening

 The Operator must ensure that only authorized actors have physical access to the underlying infrastructure.

  

Yes

security hardening  



12

 sec.gen.013

 Hardening

 The Platform must ensure that only authorized actors have logical access to the underlying infrastructure.

6.3.1 Platform Access  

Yes

security hardening  



Platform and Access (RA-1 Section 2.3.8.2)


 Ref #

 RA-1 Sub-Category

 Description

  RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

 RC Notes

1

 sec.sys.001

 Access

 The Platform must support authenticated and secure APIs, API endpoints. The Platform **must** implement authenticated and secure access to GUI

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access  



2

 sec.sys.002

 Access

 The Platform must support Traffic Filtering for workloads (for example, Fire Wall)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



3

 sec.sys.003

 Access

 The Platform must support Secure and encrypted communications, and confidentiality and integrity of network traffic

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



4

 sec.sys.004

 Access

 The Cloud Infrastructure must support Secure network channels

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



5

 sec.sys.005

 Access

 The Cloud Infrastructure must segregate the underlay and overlay networks

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



6

 sec.sys.006

 Access

 The Cloud Infrastructure must be able to utilize the Cloud Infrastructure Manager identity management capabilities

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

No

Keystone

(installed as part of OpenStack core services)

security access



7

 sec.sys.007

 Access

 The Platform must implement controls enforcing separation of duties and privileges, least privilege use and least common mechanism (Role-Based Access Control)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

Functional

Functest

RBAC

8

 sec.sys.008

 Access

 The Platform must be able to assign the Entities that comprise the tenant networks to different trust domains. (Communication between different trust domains is not allowed, by default.)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



9

 sec.sys.009

 Access

 The Platform must support creation of Trust Relationships between trust domains. These maybe uni-directional relationships where the trusting domain trusts another domain (the “trusted domain”) to authenticate users for them or to allow access to its resources from the trusted domain.  In a bidirectional relationship both domain are “trusting” and “trusted”.

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Yes

security access



10

 sec.sys.010

 Access

 For two or more domains without existing trust relationships, the Platform must not allow the effect of an attack on one domain to impact the other domains either directly or indirectly

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

No

security access



11

 sec.sys.011

 Access

 The Platform must not reuse the same authentication key-pair (for example, on different hosts, for different services)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

No

security access



12

 sec.sys.012

 Access

 The Platform must only use secrets encrypted using strong encryption techniques, and stored externally from the component (e.g., Barbican (OpenStack))

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

No

Barbican

(installed as part of OpenStack core services)

security access



13

 sec.sys.013

 Access

 The Platform must provide secrets dynamically as and when needed

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

No

Barbican

(installed as part of OpenStack core services)

security access



Confidentiality and Integrity (RA-1 Section 2.3.8.3)


 Ref #

 RA-1 Sub-Category

 Description

 RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

 RC Notes

1

 sec.ci.001

 Confidentiality/Integrity

 The Platform must support Confidentiality and Integrity of data at rest and in-transit

 [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

Keystone

(installed as part of OpenStack core services)

security confidentiality & integrity



2

 sec.ci.003

 Confidentiality/Integrity

 The Platform must support Confidentiality and Integrity of data related metadata

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

security confidentiality & integrity



3

 sec.ci.004

 Confidentiality

 The Platform must support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant).

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

 Functional

 Functest

Tenant isolation

4

 sec.ci.005

 Confidentiality/Integrity

 The Platform must support Confidentiality and Integrity of process-related metadata and restrict information sharing with only the process owner (e.g., tenant).

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

security confidentiality & integrity



5

 sec.ci.006

 Confidentiality/Integrity

 The Platform must support Confidentiality and Integrity of workload resource utilization (RAM, CPU, Storage, Network I/O, cache, hardware offload) and restrict information sharing with only the workload owner (e.g., tenant).

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

security confidentiality & integrity



6

 sec.ci.007

 Confidentiality/Integrity

 The Platform must not allow Memory Inspection by any actor other than the authorized actors for the Entity to which Memory is assigned (e.g., tenants owning the workload), for Lawful Inspection, and by secure monitoring services. Admin access must be carefully regulated 

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No

security confidentiality & integrity



7

 sec.ci.008

 Confidentiality

 The Cloud Infrastructure must support tenant networks segregation

 [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

No
OpenStack inherent capability

 Functional

Functest

Tenant isolation

Workload Security (RA-1 Section 2.3.8.4)


 Ref #

 RA-1 Sub-Category

 Description

 RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

RC Notes

1

 sec.wl.001

 Workload

 The Platform must support Workload placement policy

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No
Nova/placement

security workload



2

 sec.wl.002

 Workload

 The Platform must support operational security

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No

security workload



3

 sec.wl.003

 Workload

 The Platform must support secure provisioning of workloads 

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No

security workload



4

 sec.wl.004

 Workload

 The Platform must support Location assertion (for mandated in-country or location requirements)

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No

security workload



5

 sec.wl.005

 Workload

 Production workloads must be separated from non-production workloads

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No

security workload

6

 sec.wl.006

 Workload

 Workloads must be separable by their categorisation (for example, payment card information, healthcare, etc.)

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

No

security workload



Image Security (RA-1 Section 2.3.8.5)


 Ref #

 RA-1 Sub-Category

 Description

  RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

RC Notes

1

 sec.img.001

 Image

 Images from untrusted sources must not be used

6.3.5 Image Security

No

security image



2

 sec.img.002

 Image

 Images must be maintained to be free from known vulnerabilities

6.3.5 Image SecurityNo
Internal image scanning tool

security workload



3

 sec.img.003

 Image

 Images must not be configured to run with privileges higher than the privileges of the actor authorized to run them

6.3.5 Image SecurityNo

security workload

4

 sec.img.004

 Image

 Images must only be accessible to authorized actors

6.3.5 Image SecurityNo

security workload



5

 sec.img.005

 Image

 Image Registries must only be accessible to authorized actors

6.3.5 Image SecurityNo

security workload

6

 sec.img.006

 Image

 Image Registries must only be accessible over secure networks

6.3.5 Image SecurityYes

security workload



7

 sec.img.007

 Image

 Image registries must be clear of vulnerable and stale (out of date) versions

6.3.5 Image SecurityNo

security workload



Security LCM (RA-1 Section 2.3.8.6)


 Ref #

 RA-1 Sub-Category

 Description

 RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

 RC Notes

1

 sec.lcm.001

 LCM

 The Platform must support Secure Provisioning, Maintaining availability, Deprovisioning (secure Clean-Up) of workload resources; Secure clean-up: tear-down, defending against virus or other attacks, or observing of cryptographic or user service data

(7.2.2. Configuration Management)

Yes

security LCM



2

 sec.lcm.002

 LCM

 Operational must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS

(7.2.2. Configuration Management)

Yes

security LCM



3

 sec.lcm.003

 LCM

 The Cloud Operator must implement change management for Cloud Infrastructure, Cloud Infrastructure Manager and other components of the cloud; Platform change control on hardware

(7.2.2. Configuration Management)

No

security LCM



4

 sec.lcm.005

 LCM

 Platform must provide logs and these logs must be regularly scanned

6.3.7 Security Audit Logging

Yes

security LCM



5

 sec.lcm.006

 LCM

 The Platform must verify the integrity of all Resource management requests

6.3.7 Security Audit Logging

No

security LCM

6

 sec.lcm.007

 LCM

 The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information

(7.2.2. Configuration Management)

No

security LCM

7

 sec.lcm.008

 LCM

 The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information.

(7.2.2. Configuration Management)

No

security LCM



8

 sec.lcm.009

 LCM

 The Platform must be able to update the tag of newly instantiated, suspended, hibernated, migrated and restarted images with relevant geolocation (geographical) information

(7.2.2. Configuration Management)

No

security LCM



9

 sec.lcm.010

 LCM

 The Platform must log all changes to geolocation along with the mechanisms and sources of location information (i.e. GPS, IP block, and timing).

(7.2.2. Configuration Management)

No

security LCM



10

 sec.lcm.011

 LCM

 The Platform must implement Security life cycle management processes including proactively update and patch all deployed Cloud Infrastructure software.

(7.2.2. Configuration Management)

No

security LCM



Monitoring and Security Audit (RA-1 Section 2.3.8.7)

The Platform is assumed to provide configurable alerting and notification capability and the operator is assumed to have automated systems, policies and procedures to act on alerts and notifications in a timely fashion. In the following the monitoring and logging capabilities can trigger alerts and notifications for appropriate action.


 Ref #

 RA-1 Sub-Category

 Description

 RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

RC Notes

1

 sec.mon.001

 Monitoring/Audit

 Platform must provide logs and these logs must be regularly scanned for events of interest

7.4.1. Logging

Yes




2

 sec.mon.002

 Monitoring

 Security logs must be time synchronised

6.3.7 Security Audit Logging  and 7.4.1. Logging

Yes




3

 sec.mon.003

 Monitoring

 The Platform must log all changes to time server source, time, date and time zones

7.4.1. Logging

Yes




4

 sec.mon.004

 Audit

 The Platform must secure and protect Audit logs (contain sensitive information) both in-transit and at rest

6.3.7 Security Audit Logging  and 7.4.1. Logging

Yes




5

 sec.mon.005

 Monitoring/Audit

 The Platform must Monitor and Audit various behaviours of connection and login attempts to detect access attacks and potential access attempts and take corrective actions accordingly

7.4. Logging, Monitoring and Analytics (includes Alerting)

No




6

 sec.mon.006

 Monitoring/Audit

 The Platform must Monitor and Audit operations by authorized account access after login to detect malicious operational activity and take corrective actions accordingly

7.4. Logging, Monitoring and Analytics (includes Alerting)

No




7

 sec.mon.007

 Monitoring/Audit

 The Platform must Monitor and Audit security parameter configurations for compliance with defined security policies

7.2.2. Configuration Management

No




8

 sec.mon.008

 Monitoring/Audit

 The Platform must Monitor and Audit externally exposed interfaces for illegal access (attacks) and take corrective security hardening measures

7.4. Logging, Monitoring and Analytics (includes Alerting)No




9

 sec.mon.009

 Monitoring/Audit

 The Platform must Monitor and Audit service handling for various attacks (malformed messages, signalling flooding and replaying, etc.) and take corrective actions accordingly

7.4. Logging, Monitoring and Analytics (includes Alerting) - partial

No




10

 sec.mon.010

 Monitoring/Audit

 The Platform must Monitor and Audit running processes to detect unexpected or unauthorized processes and take corrective actions accordingly

(7.4. Logging, Monitoring and Analytics (includes Alerting))No




11

 sec.mon.011

 Monitoring/Audit

 The Platform must Monitor and Audit logs from infrastructure elements and workloads to detected anomalies in the system components and take corrective actions accordingly

7.4. Logging, Monitoring and Analytics (includes Alerting)

No




12

 sec.mon.012

 Monitoring/Audit

 The Platform must Monitor and Audit Traffic patterns and volumes to prevent malware download attempts

(7.4. Logging, Monitoring and Analytics (includes Alerting))

No




13

 sec.mon.013

 Monitoring

 The monitoring system must not affect the security (integrity and confidentiality) of the infrastructure, workloads, or the user data (through back door entries).

(7.4.4. Logging, Monitoring, and Analytics (LMA) Framework)

No




14

 sec.mon.015

 Monitoring

 The Platform must ensure that the Monitoring systems are never starved of resources


Yes




15

 sec.lcm.017

 Audit

 The Platform must Audit systems for any missing security patches and take appropriate actions

(7.2.2. Configuration Management)

No




Compliance with Standards (RA-1 Section 2.3.8.8)


 Ref #

 RA-1 Sub-Category

 Description

  RA-1 Traceability

RI ApplicableRI ToolsetRI Notes

 RC Category

 RC Toolset

 RC Notes

1

 sec.std.018

 Standards

 The Public Cloud Operator must, and the Private Cloud Operator may be certified to be compliant with the International Standard on Awareness Engagements (ISAE) 3402 (in the US: SSAE 16); International Standard on Awareness Engagements (ISAE) 3402. US Equivalent: SSAE16


NoNA



  • No labels