-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAI RAN NF custom controller - initial version #1
Conversation
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this first version.
I believe that we must discuss more on the 3gpp parameters and be aligned with the one used for the core.
For example, we should have a list of cells
Some parameters must be required (eg mcc and mnc and in plmn)
all the api definitions should go to /nephio/api repo. Also there is no point of redefining the nf deployment since it already exists in the api repo |
I have some remarks about interface's name in config/samples/randeploymentcuup.yaml file. In line 48 should be f1u interface name not f1c. It should be checked whether the name of network instance is correct in line 46 -(vpc-f1c). Also there is inconsistency with interface's name in line 45 is "e1" and in line 29 is "e1-cu-up" . |
In file /internal/controller/resources_cuup.go there is inconsistency in messages in log.Error: |
Removing nf_deployment redefinitions Corrections of logging information and yamls Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
Thanks @henderiw for the review comment. I have removed the redefinitions of nf deployment. Regarding API definitions for RAN deployment, I have kept it for temporary reference for the initial commits. Later it will be removed and adapted to the common NF deployment. |
Thanks @iwojdan for the review comments. I have updated the file as per your comments in the latest commit. Also wanted to clarify that the files with network instances and interfaces will be generated during deployment in future. I have added these files only for initial references. |
Thanks @iwojdan for your careful review. I have updated the code as per your comments. |
Hi @henderiw , @johnbelamaric, @tliron, @s3wong. I have updated the pr based on the comments received. Let me if you have any more comments and if this initial commit can be merged ? |
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: josephthaliath The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
Signed-off-by: josephthaliath <jo.thaliath@samsung.com>
@@ -33,7 +33,7 @@ type CuUpResources struct { | |||
|
|||
func (resource CuUpResources) createNetworkAttachmentDefinitionNetworks(templateName string, ranDeploymentSpec *nephiov1alpha1.NFDeploymentSpec) (string, error) { | |||
return free5gccontrollers.CreateNetworkAttachmentDefinitionNetworks(templateName, map[string][]nephiov1alpha1.InterfaceConfig{ | |||
"e1": free5gccontrollers.GetInterfaceConfigs(ranDeploymentSpec.Interfaces, "e1-cu-up"), | |||
"e1": free5gccontrollers.GetInterfaceConfigs(ranDeploymentSpec.Interfaces, "e1"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephthaliath I feel there is some sort of linking if we are using code from the free5gc repository (free5gccontrollers library from free5g/controller). I guess the better way would be to abstract this kind of code in a common repo something like utils and then use it between both of the repositories. But I suppose that will be some extra work. We should do in R3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes right. We need to propose these functions to a common place. Since now we have common NFDeployment, any functions defined for this, can be reused across all NFs,
config/samples/cucp_config.yaml
Outdated
name: oai-ran-cu-cp | ||
namespace: oai-ran | ||
spec: | ||
provider: oai-cucp.nephio.org |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephthaliath for OAI can we use the same provider? I will use {NF_TYPE}.openairinterface.org
. For example, for UPF it will be --> upf.openairinterface.org
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arora-sagar , Sure I will update it. Also you can check the initial packages PR for reference and review. nephio-project/catalog#3
api/v1alpha1/ranconfig_types.go
Outdated
|
||
// NOTE: For R2 the DNN.name here should match with NF deployment DNN name. This is a hack for R2 | ||
// DNN defines the Data Network Names Information | ||
type DNNInfo struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephthaliath Are you still using it? I think you can remove the DNN part from your section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josephthaliath Are you still using it? I think you can remove the DNN part from your section.
@arora-sagar, I added it initially from the PR#57, in anticipation that will be used. I remove this.
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some code optimisation proposed
|
||
package controller | ||
|
||
func int32Ptr(val int) *int32 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a pointer library for this
e.g. "k8s.io/utils/pointer"
return &a | ||
} | ||
|
||
func int64Ptr(val int) *int64 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a pointer library for this
e.g. "k8s.io/utils/pointer"
return &a | ||
} | ||
|
||
func boolPtr(val bool) *bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a pointer library for this
e.g. "k8s.io/utils/pointer"
workloadv1alpha1 "github.com/nephio-project/api/workload/v1alpha1" | ||
) | ||
|
||
func GetInterfaceConfigs(interfaceConfigs []workloadv1alpha1.InterfaceConfig, interfaceName string) []workloadv1alpha1.InterfaceConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should create a library which we can reuse between all NF implementation that use NF Deployment.
Version: "v1", | ||
} | ||
|
||
func CreateNetworkAttachmentDefinitionNetworks(templateName string, interfaceConfigs map[string][]workloadv1alpha1.InterfaceConfig) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a library should be used for reuse between NF(s)
|
||
} | ||
|
||
func (r *RANDeploymentReconciler) DeleteAll(log logr.Logger, ctx context.Context, ranDeployment *workloadv1alpha1.NFDeployment, nfResource NfResource, configInfo *ConfigInfo) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should use
log.FromContext(ctx) iso passing the logr as a fn param.
// - https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.15.0/pkg/reconcile | ||
func (r *RANDeploymentReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { | ||
|
||
logger := log.FromContext(ctx).WithValues("RANDeployment", req.NamespacedName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is how we should use logger iso passing it via the fn param
setupLog.Error(err, "Not able to register workload/v1alpha1 NFDeployment kind") | ||
} | ||
|
||
if err = (&controller.RANDeploymentReconciler{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be better ti use the pattern w have in core so we can add/delete reconcilers easily.
https://github.com/nephio-project/nephio/blob/1c3aa4d9435f369f707fe9b5587c680cc0e50b4d/operators/nephio-controller-manager/main.go#L165
return []*corev1.ConfigMap{configMap1} | ||
} | ||
|
||
func (resource DuResources) GetDeployment(log logr.Logger, ranDeployment *workloadv1alpha1.NFDeployment, configInfo *ConfigInfo) []*appsv1.Deployment { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should make libs for these so people can reuse these
The other part is test coverage need to be improved |
Related issue: nephio-project/nephio#364
Note: Used the initial RANDeployment CRD in this version. Will adapt to common NFDeployment CRD.