6 Uninstalling NSSF

This chapter provides information about uninstalling Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF).

6.1 Uninstalling NSSF Using Helm

Note:

NSSF does not automatically remove the entries from the ProvisionDB or StateDB during the uninstall process. All records created in these databases remain intact after the uninstallation. If a clean environment is required, these entries must be manually removed or the databases must be reset by the administrator.

To uninstall NSSF, run the following command:

helm uninstall <helm-release> --namespace <release-namespace> 

Where,

<helm-release> is a name provided by the user to identify the helm deployment.

<release-namespace> is a name provided by the user to identify the namespace of NSSF deployment.

For example:

helm uninstall ocnssf --namespace ocnssf

To verify the NSSF uninstallation, run the following command:

$ kubectl get all -n <release-namespace>

In case of successful uninstallation, no NSSF resource is displayed in the command output.

If the command output displays the NSSF resources or objects, then perform Deleting Kubernetes Resources.

If the command output displays any Kubernetes namespace, then perform the Chunk1726367272.html#GUID-49D8357D-4EE2-4A78-B024-39F0F9977E56.

6.2 Creating Service Account, Role, and RoleBinding

This section is mandatory and it describes how to manually create a service account, role, and rolebinding. It is required only when customer needs to create a role, rolebinding, and service account manually before installing NSSF.

Note:

• The secret(s) should exist in the same namespace where NSSF is getting deployed. This helps to bind the Kubernetes role with the given service account.
• This procedure is applicable to all NSSF environments except OpenShift. If you are using an OpenShift environment, then use the Verifying and Creating Namespace in an OpenShift Environment procedure to create namespace, service accounts, roles, and role bindings.

Creating Service Account, Role, and RoleBinding

1. Run the following command to create a NSSF resource file:

   vi <ocnssf-resource-file>

   Where,

   <ocnssf-resource-file> is the name of the resource file.

   Example:

   vi ocnssf-resource-template.yaml

2. Update the ocnssf-resource-template.yaml with release specific information:

   Note:

   Update <helm-release> and <namespace> with its respective NSSF namespace and NSSF Helm release name.

   A sample template to update the ocnssf-resource-template.yaml file with is given below:

   ## Sample template start## 
   # Copyright 2018 (C), Oracle and/or its affiliates. All rights reserved.
   
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: <helm-release>-ocnssf-serviceaccount
     namespace: <namespace>
   ---
   
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: <helm-release>-ocnssf-role
     namespace: <namespace>
   rules:
   - apiGroups:
     - "" # "" indicates the core API group
     resources:
     - services
     - configmaps
     - pods
     - secrets
     - endpoints
     - persistentvolumeclaims
     - serviceaccounts
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - policy
     resources:
     - poddisruptionbudgets
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - apps
     resources:
     - deployments
     - statefulsets
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - autoscaling
     resources:
     - horizontalpodautoscalers
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - rbac.authorization.k8s.io
     resources:
     - roles
     - rolebindings
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - monitoring.coreos.com
     resources:
     - prometheusrules
     verbs:
     - get
     - watch
     - list
     - update
   - apiGroups:
     - discovery.k8s.io
     resources:
     - endpointslices
     verbs:
     - get
     - list
     - watch
   ---
   
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: <helm-release>-ocnssf-rolebinding
     namespace: <namespace>
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: <helm-release>-ocnssf-role
   subjects:
   - kind: ServiceAccount
     name:  <helm-release>-ocnssf-serviceaccount
     namespace: <namespace>
   ---
   
   ## Sample template end#

3. Run the following command to create service account, role, and rolebinding:

   $ kubectl -n <namespace> create -f ocnssf-resource-template.yaml

   Where,

   <namespace> is the namespace where NSSF is deployed.

   Example:

   $ kubectl -n ocnssf create -f ocnssf-resource-template.yaml

4. Update the serviceAccountName parameter in the ocnssf_custom_values_25.2.202.yaml file with the value updated in name field under kind: ServiceAccount. For more information about serviceAccountName parameter, see the Global Parameters section.

Note:

PodSecurityPolicy kind is required for Pod Security Policy service account. For more information, see Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.

Verifying and Creating Namespace in an OpenShift Environment

Perform the following steps to create namespace in an OpenShift environment:

1. Run the following command to create a namespace:

   $ oc create namespace <namespace>

2. Follow the below steps to create and apply security context constraints:
   1. Run the following command to create a security context constraints file:

      vi <security-context-constraints-file>

      Where,

      <security-context-constraints-file> is the name of the security context constraints file.

      Example:

      vi ocnssf_scc_openshift.yaml

   2. Update the ocnssf_scc_openshift.yaml with release specific information:

      kind: SecurityContextConstraints
      apiVersion: security.openshift.io/v1
      metadata:
        name: ocnssf-scc
      priority: 1
      allowHostDirVolumePlugin: false
      allowHostIPC: false
      allowHostNetwork: false
      allowHostPID: false
      allowHostPorts: false
      allowPrivilegeEscalation: true
      allowPrivilegedContainer: false
      allowedCapabilities: null
      defaultAddCapabilities: null
      requiredDropCapabilities:
      - KILL
      - MKNOD
      - SETUID
      - SETGID
      - NET_RAW
      users: []
      groups: []
      fsGroup:
        type: RunAsAny
      readOnlyRootFilesystem: false
      runAsUser:
        type: MustRunAsNonRoot
      seLinuxContext:
        type: MustRunAs
      supplementalGroups:
        type: RunAsAny
      volumes:
      - configMap
      - downwardAPI
      - emptyDir
      - persistentVolumeClaim
      - projected
      - secret

   3. Run the following command to apply ocnssf_scc_openshift.yaml file with the updated content:

      $ oc apply -f ocnssf_scc_openshift.yaml -n <namespace>

      Where,

      <namespace> is the NSSF namespace.

3. Follow the below steps to create and apply the required service accounts, role, and role bindings:
   1. Run the following command to create a service accounts, role, and role bindings file:

      vi <rbac-file>

      Where,

      <rbac-file> is the name of the service accounts, role, and role bindings file.

      Example:

      vi ocnssf_rbac_openshift.yaml

   2. Update the ocnssf_rbac_openshift.yaml with release specific information:

      ---
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: ocnssf-ssc-serviceaccount
        namespace: <namespace>
      ---
       kind: Role
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         name: ocnssf-ssc-role
       rules:
         - apiGroups: ["security.openshift.io"]
           resources: ["securitycontextconstraints"]
           resourceNames: ["ocnssf-scc"]
           verbs: ["use"]
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: ocnssf-ssc-rolebinding
        namespace: <namespace>
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: ocnssf-ssc-role
      subjects:
      - kind: ServiceAccount
        name: ocnssf-ssc-serviceaccount
      - kind: ServiceAccount
        name: default
      ---

   3. Run the following command to apply ocnssf_rbac_openshift.yaml file with the updated content:

      $ oc apply -f ocnssf_rbac_openshift.yaml -n <namespace>

      Where,

      <namespace> is the NSSF namespace.

4. Follow the below steps to create and apply the required NetworkAttachmentDefinition:
   1. Run the following command to create a NetworkAttachmentDefinition file:

      vi <nad-file>

      Where,

      <nad-file> is the name of the NetworkAttachmentDefinition file.

      Example:

      vi ocnssf_nad.yaml

   2. Update the ocnssf_nad.yaml with release specific information:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: istio-cni
      spec:
        config: ""

   3. Run the following command to apply ocnssf_nad.yaml file with the updated content:

      $ oc apply -f ocnssf_nad.yaml -n <namespace>

      Where,

      <namespace> is the NSSF namespace.

5. Run the following command to configure the ocnssf-scc Security Context Constraint (SCC) to the service accounts in the ocnssf namespace:

   $ oc adm policy add-scc-to-group ocnssf-scc system:serviceaccounts:<namespace> -n <namespace>

   Where,

   <namespace> is the NSSF namespace.

6.3 Deleting Kubernetes Resources

This section describes how to delete Kubernetes resources or objects where NSSF is deployed.

1. Run the following command to delete all the Kubernetes objects:

   kubectl delete all --all -n <release-namespace>

2. Run the following command to delete all the configmaps:

   kubectl delete cm --all -n <release-namespace>

   Caution:

   If the user has created RBAC and service account details before Helm, installing in the same namespace is required, do not delete RBAC and service account details. In case a custom service account is not provided by the user, and it is safe to remove it, then run the following commands to delete the resources or objects which are not required.
3. Run the following command to delete the specific resources:

   kubectl delete <resource-type> <resource-name> -n <release-namespace>

6.4 Removing Database Users

This section describes how to remove MySQL users.

To remove MySQL users while uninstalling NSSF, run the following commands:

Remove Privileged User:

$ DROP USER IF EXISTS <NSSF Privileged-User Name>;

For example:

$ DROP USER IF EXISTS nssfprivilegedusr';

Remove Application User:

$ DROP USER IF EXISTS <NSSF Application User Name>;

For example:

$ DROP USER IF EXISTS nssfusr;

Caution:

Removal of users must be done on all the SQL nodes for all NSSF sites.

6.5 Cleaning up Database

This section describes how to clean up database when uninstalling NSSF.

6.5.1 Single Site

Run the following command to remove NSSF database on single site setup:

Remove State Database:

$ DROP DATABASE if exists <NSSF state database>;

For example:

$ DROP DATABASE if exists nssfStateDB;

Remove Provision Database:

$ DROP DATABASE if exists <NSSF provision database>;

For example:

$ DROP DATABASE if exists nssfProvSiteDB;

Remove Release Database:

$ DROP DATABASE if exists <NSSF release database>;

For example:

$ DROP DATABASE if exists ocnssfReleaseDB;

Remove Leaderpod Database:

$ DROP DATABASE if exists <NSSF Leaderpod Database>;

For example:

$ DROP DATABASE if exists LeaderPodDb;

6.5.2 Multisite

Run the following command to remove NSSF database on multisite setup:

Note:

For georedundant deployments, do not remove the State and Release database directly. Wait until all the sites are down first, then remove the database.

Note:

For georedundant deployment, run the commands provided in this section only if the site being uninstalled is the last site in the complete georedundant group.

Remove State Database:

$ DROP DATABASE if exists <NSSF state database>;

For example:

$ DROP DATABASE if exists nssfStateDB;

Remove Provisional Database:

$ DROP DATABASE if exists <NSSF provision database>;

For example:

Site 1:

$ DROP DATABASE if exists nssfProvSite1DB;

Site 2:

$ DROP DATABASE if exists nssfProvSite2DB;

Site 3:

$ DROP DATABASE if exists nssfProvSite3DB;

Remove Release Database:

$ DROP DATABASE if exists <NSSF release database>;

For example:

$ DROP DATABASE if exists ocnssfReleaseDB;

Remove Leaderpod Database:

$ DROP DATABASE if exists <NSSF Leaderpod Database>;

For example:

Site 1:

$ DROP DATABASE if exists LeaderPod1Db;

Site 2:

$ DROP DATABASE if exists LeaderPod2Db;

Site 3:

$ DROP DATABASE if exists LeaderPod3Db;