Epic - Implement NF Topology controller

[gvbalaji]

Implement, build and unit test NF topology controller. The code will reside in nephio-controllers repo.

This controller processes the NFTopology resources, emitting PackageVariant[Set] resources as well as other NF-specific resources.The NFTopology resource captures a set of network function configurations, as well as the clusters (or perhaps sites) in which those functions, with those specifications, should be deployed and operational.The NFTopology resource itself may point to other, NF-specific resources for the details of those configurations.

The key is that the NF configuration captured here is that aspect which is invariant across the sites. Variance across the sites is introduced via injection.

In the PoC, this was called the FiveGCoreTopologyController. This is a more generalized version of that, which we may reconsider if there is some 5G Core semantics we want built in; however, at this point it does not seem necessary.

In the PoC, this controller use a very sparse seed package as the upstream when it created PackageDeployment (the predecessor of PackageVariant[Set]), and the actual NF configuration was then injected by the NF Injector Controller. An alternative would be for this controller to combine the sparse seed with knowledge built into this to create a new package, and then use that package as the upstream in the PackageVariant[Set]. This is the approach taken in the Google seed code.

This is an umbrella issue This issue comprises of following tasks

• Design document for the NF Topology controller #96
• Implement the NF Topology controller and write unit tests. #97
• Track topology of the deployment intent, and updates aggregated status in NF Topology controller #98

[johnbelamaric]

Closing this, as we have moved to using composition of resources inside a package, and then using PackageVariant/PackageVariantSet resources to actuate the distribution across cluster topologies. That is, we manually create a package containing PackageVariantSets and use config injection, rather than having a controller create those.

This document explains it a bit more: https://docs.google.com/document/d/1wAgPO0IDyN-UqpB3twv3e-9mumck-5o3j8f74FLkKPI/edit?usp=sharing

See also https://docs.google.com/document/d/1wtA5BJnn1GGq-yWa7FUAOrCJuyQqifB3f4ky-IePIzo/edit#heading=h.atc9ypf4hfox

@kispaljr also put together this diagram, which shows this really nicely - with the caveat that it currently shows the NF Topology controller. Comments from Slack regarding this diagram:

1. For R1, I think we can get away without a topo CR and controller, and just have humans create a "5G Packet Core" organizational blueprint.
2. This also means we wouldn't have "pre-fanout injectors", which I am taking to mean "package specializers" of the 5g package core package.
3. Instead, at least for R1 that will be manual. This I think you have drawn, where you have "Network Service Designer" and "Infrastructure Operator", the difference being you are not showing the upstream "5G Package Core" package they start with.
4. So, for example the organizational version of the 5g package core package would have a placeholder "3gpp config" resource with say PLMN stuff. When that is cloned to the mgmt cluster deployment repo, the deployer would set the correct PLMNID in there. The PVS would configure each PV to inject this (static, identical) resource in each resulting package revision.
5. This is in addition to the cluster contexts. PVS would configure each PV to inject a different cluster context in each PR, based on the target.

[johnbelamaric]

/reopen

[johnbelamaric]

/assign s3wong

[johnbelamaric]

/retitle Epic: NF Topology Controller

[johnbelamaric]

@gvbalaji Maybe we should schedule the "Epic" umbrella issues against the R1 milestone, and the sub-issues against each sprint?

[MA3CIN]

I believe there were some talks (on SIG Automation - was it @johnbelamaric ?) about the Topology Controller selecting an edge cluster to deploy NFs on based on available (cluster) resources - is this planned for R2? Would this be the component responsible for cluster selection? Can't seem to find any other issues describing this functionality

[henderiw]

The sub bullet a for R2 might do this, but we haven’t finalised the scope. You will see that the NF2infra has a bullet regarding this.

…

On 1 Sep 2023, at 02:59, Marcin Ziółkowski ***@***.***> wrote: I believe there were some talks (on SIG Automation - was it @johnbelamaric <https://github.com/johnbelamaric> ?) about the Topology Controller selecting an edge cluster to deploy NFs on based on available (cluster) resources - is this planned for R2? Would this be the component responsible for cluster selection? Can't seem to find any other issues describing this functionality — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMXXVHZAZUS3EGA5RXOX6TXYGWYJANCNFSM6AAAAAAU4GOSSI>. You are receiving this because you are subscribed to this thread.

[MA3CIN]

The sub bullet a for R2 might do this, but we haven’t finalised the scope. You will see that the NF2infra has a bullet regarding this.

"Enhance the Infra CRs to meet the needs for NFs-related infra provisioning" - got it.

[s3wong]

@MA3CIN That is an interesting topic; the NFTopology CRD today only takes cluster label as selector to instantiate NFInstance; there are a number of options for us to influence the NFInstance placement (the following is just an example list, absolutely not comprehensive):

1. enhance CRD to also include selector for infra --- this seems far too complicated to be specified on {key, value} string format
2. add infra logic in NFTopology controller --- this seems inappropriate as the NFTopology controller is meant to maintain inter-NF connectivity info (and which vendor and what capacity specified) ... so it is more of a user interface (i.e., intent input). Our design principle has always been avoiding to overload a controller to do more than it is meant to do
3. have a cluster / infra controller setting additional labels to cluster context to trigger NFInstance to be deployed. The NFTopology still needs specification (statically) on the label to match --- and today we only assume region and cluster labels (ex: {region: region-west, cluster: edge}); we can make a label that is slightly more dynamic by adding say labels for {vendor-nfflavor: } which maps to a vendor string {-} NF flavor -- something that the NFTopology controller can generate based on input on NFInstance specification, and the infra controller can determine if a cluster can narrow if a cluster (infra controller tracks the capacity and supported features of a cluster) can satisfy particular vendor - nfflavor; infra controller (presumably, when one onboards a NF, it would register with infra controller what it needs to satisfy a NF flavor; I am also assuming infra controller is infra provider specific) can thereby tag the cluster accordingly every time a new cluster is created

(one can imagine a lot of complex stuff to make this work --- including enhancing NFTopology CRD to allow user to specify the minimum number of a "sub-deployment", i.e., a specification of a {SMF: [UPFs]} should at least have N instances, and the infra controller could consult that info from NFToplogy controller to make intelligent decision on appropriate label to apply to a cluster)

Anyway, I am still assuming no major change on NFTopology controller, and will work on repost the patch (there was some changes to the CRDs due to comments since my old patch, hence needs to update) hopefully this week.