[RM Ch2] Review analysis and whether the documented cloud infrastructure profiles need modifying/adding to

[tomkivlin]

From vF2F in October: https://etherpad.opnfv.org/p/Gathering_and_Validating_CNF_Requirements

Parent/child relationship is something to consider
SW developers would work to a child profile - automatically conforms to parent profile

Purpose of this is to consider more granular profiles to allow for a wide range of deployment scenarios.

[tomkivlin]

I will try to join the meeting on 11/11, but the discussion was about the profiles that were created in the workloads analysis chapter (https://github.com/cntt-n/CNTT/blob/master/doc/ref_model/chapters/chapter02.md).

The idea was that today, a platform provider would need to deliver all requirements for e.g. Network Intensive in order for an operator to be happy running something like a 5G user plane application. However, that provider may also have a different platform for radio applications, or a different provider may only target radio applications. An operator (maybe only the larger ones, I don't know) may choose to have different vendors (or at least, different selection processes) for these different parts of the network. These different areas may need only a subset of the "Network Intensive" profile - e.g. low latency - and so it would be more efficient to allow the platform providers to choose if they want to target just a child profile (e.g. just for radio) or if they want to target all profiles under Network Intensive, and the operators can then choose accordingly. That's just one example, as there will be others for public cloud etc.

[wmk-admin]

Needs to be discussed at RM with @tomkivlin, post- Elbrus

[rgstori]

Notes from RA2:

• need to differentiate between Profiles and Flavours,
• need to differentiate between workload profiles vs infrastructure/node profiles
• Operators are generally against proliferation of profiles
• Profiles segment/partition the infrastructure: nodes belonging to different profiles are managed separately
• too much optionality in profile specs, gives too little assurance to users
• Hierarchical profiles: flavours as sub-profiles?
• need to maximise capacity - segmenting infrastructure with mono-dimensional profiles leads to waste of capacity when workloads are forced to choose a set partition to be allocated onto at runtime
• need to rename the network-intensive profile to something else as it's misleading - eg basic vs advanced?

I will formulate a proposal with hierarchical profiles (profile.flavour), so that we can define flavours within a profile without partitioning the infrastructure. Workloads should be able to specify the infrastructural requirement using either (ie only profile for a lax requirement, profile and flavours for a more granular, stricter selection)