Initial draft for NFTopology Controller design doc #5
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: s3wong The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
s3wong
changed the title
|
|
||
|  | ||
|
|
||
| Note that the NetworkInstance field is static, i.e., user defined a fixed NetworkInstance resource to be linked to a template, whereas the actual NF instance is dynamic --- that is, the actuation of the instance of the NF is based off of a cluster matching some labels, but the NetworkInstace this NF specification will be attaching to is statically configured. Note that each NFInstance would only create one instance per each cluster matching a label, and that the NFNetworkInstance does **NOT** define the network, it is merely |
There was a problem hiding this comment.
PackageVariantSet allows you to provide a static list of repositories. Would that work better in this case than labels?
|
|
||
| | NFTopology or associated | PVS Spec field | | ||
| |:------------------------ | :------------- | | ||
| | NFTopology.NFInstance.NFTemplate.ClassRef.PackageRevisionRef | Upstream (*Tag* is missing from PackageRevisionRef... Revision?) | |
There was a problem hiding this comment.
Yes, Revision is the tag. It's not a general-purpose git tag, but rather expected to be a tag in the form "packagename/vX". These tags are automatically created by Porch when a package is published. You refer to it as "vX". See https://github.com/nephio-project/nephio-example-packages/blob/5aadec6d8f9b301a5f775797791aa5e0c0536cc0/5g-core-topology/packagevariantset-amf-regional.yaml#L6 for an example.
| | NFTopology.NFInstance.ClusterSelector | Targets[0].Repositories | | ||
| | {nf-deployment-name : *name of NFTopology CR* | Labels[] | | ||
|
|
||
| The assumption here is that (at least a subset of) the ClusterSelector labels will be used to also label the repositories, i.e., target workload cluster with label `region == x; cluster-role == y` will also be part of the labels to use on a deployment repo of a target workload cluster. |
There was a problem hiding this comment.
I would suggest labeling it with a label based on this NFTopology resource name, so that you can aggregate it specifically for this NFTopology. You also add the NFTopology to the ownerReferences on the PVSs. But the labels (e.g., nf.nephio.org/topology or something) can be used in watches and can, like you say, be propagated all the way down to the PackageRevisions.
| particular purpose. | ||
|
|
||
| ## Tracking Packages | ||
| NTC will embed a label 'nf-deployment-name', which is set to NFToplogy CR's own name; PackageVariantSet and PackageVariant controllers will propagate this label to all the PackageRevision resources associated with the "fan-out"ed packages. |
There was a problem hiding this comment.
Oh, I see that's already the plan!
|
|
||
| NTC watches over all PackageRevision resources in the management cluster, and maps the NFTopology intent to the number of deployed NF resources via tracking corresponding PackageRevision resources. As each PackageRevision resource gets to *PUBLISHED* state, NTC would update NFDeployedTopology resource to reflect on newly target NF deployment to monitor. | ||
|
|
||
| NTC will also extract the number of pending conditions from each of the PR as a display to user(s) who want to continuously examine the lifecycle of the packages, and which conditions are gating a particular package from being deployed. NTC essentially tracks status of package deployment for all NF instances specified derived from the NFTopology intent; however, NTC does **NOT** track the progress of the deployment once the package is pushed to the workload cluster, those statues |
There was a problem hiding this comment.
@MuhammadSaheerCheruvath @ganchandrasekaran This could be something we look at for the Nephio tab in the UI
No description provided.