[RM Ch04] Rewrite 4.2 #2384
[RM Ch04] Rewrite 4.2 #2384
Conversation
pgoyal01
requested review from
rgstori,
CsatariGergely,
karinesevilla,
walterkozlowski and
a team
|
@karinesevilla commented on the wiki page, "Karine: predefined workload flavours are not really used in practice and too much associated with OpenStack and not K8s. We should remove the following table. the paragraph could be replaced by best practice sizing for VNF and CNF or examples only" Can we delete 4.2.4.1 Predefined Workload Flavours and only the header for 4.2.4.2 Parameterised/Customised Workload Flavour Sizing Syntax (leaving the 2-line para)? WOuld that work? |
@pgoyal01 Yes, it works. I think we can keep part of the notes of tables 4-13 |
Deleted <br> as it seems not to be working within a Table cell
|
@CsatariGergely stated
@CsatariGergely in Issue #2354, the source for 3 of the items (cpu architecture, hypervisor and operating system) was pointed out. The hypervisor situation was explicitly discussed within CNTT and is mentioned in the common/chapter00.md. RA1 Section 4.2.1 mentions "different hardware platforms (x86, Power)" as we always had the intent that the CPU hardware architecture could be different -- we just didn't list i in the capabilities. Operating System variations, is again a very obvious oversight. SMT is listed in the diagrams but somehow is missing from the capability tables. affinity, non-affinity are important workload placement capabilities that we somehow missed; as did OPG. We have been discussing latency w.r.t many of the workloads and hence the add. So we are missing certain capabilities that need mitigating irrespective of who pointed them out. |
|
Would you also like to capture somewhere vRAN requirements like for real time and timing accuracy? Or this comes somewhere else? |
|
@pgoyal01 Add "dedicated core" - both thread assigned to the workload |
|
OPG.02 "Operator Platform Technical Requirements" uses the term "Resource Flavour" to describe the profile and flavour specified by the workload. @pgoyal01 add it to workload profile section. |
Added "Dedicated Cores" Cleaned-up some terminology and used "Resource Flavours" (as per OPG.02) -- workload flavours is now strictly for resource sizing.
|
|
||
| where the specifications enclosed within "[" and "]" are optional, and the 'extra profile specs' are needed to capture special node configurations not accounted for by the profile and profile extensions. | ||
|
|
||
| Examples, node configurations specified as: B, B.low-latency, H, and H.very-high-speed-network.very-low-latency-edge. |
There was a problem hiding this comment.
@pgoyal01
As mentioned just before, Basic profile is for workload that can tolerate variable latency. The example B.low-latency is not consistent.
There was a problem hiding this comment.
@karinesevilla I tried to conform to the content in RM 2.4.2 as they were already approved and merged.
Could we have the situation where an application can request "low latency" to be placed in a site closer to the user but where this latency is not guaranteed. The application would be designed to handle "longer" latency times.
|
|
||
| Profile Extensions represent small deviations from or further qualification of the profiles that do not require partitioning the infrastructure into separate pools, but that have specifications with a finer granularity of the profile. Profile Extensions provide workloads a more granular control over what infrastructure they can run on. | ||
|
|
||
| | Profile Extension Name | Mnemonic | Applicable to Basic Profile | Applicable to High Performance Profile | Description | Notes | |
There was a problem hiding this comment.
Profile extension should apply only to High Performance profiles
There was a problem hiding this comment.
@karinesevilla Could we, for example, host applications on edge sites for better user experience but there can be occasions where the experience may perform poorly?
Per @karinesevilla revert to use of workload flavours
Add Reference numbers from PR #2399 to new entries in Section 4.2. Correct minor typs.
* [RM Ch04] Update Section 4.1 capabilities Fixes #2398 Update Section 4.1 with missing capabilities * [RM Ch04] Move 4.1.7 to 4.1.2.4 As per suggestion by @karinesevilla * [RM Ch4] TYpo correction in 4.1.4.3 "secuirty" -> "security". Thanks @petorre
|
PR #2320 was merged and so the content of this PR needed to take that into account and the conflicts it generated. Created PR #2450 so as to avoid conflicts. @walterkozlowski I recommend that we abandon this PR #2384 and concentrate now on PR #2450. Thanks |
|
As decided at RM Meeting on 26 May 2021, we can close this pR as the related work is going on in PR#2450 |
Fixes #2366
The rewrite is as per the changes made by @rgstori in RM Section 2.4 and discussions with the GSMA Operator Platform Group (OPG) team members.
Please note that the variations from some of the terminology used in RM Section 2.4 will be addressed separately