Update best-practices-onboard-deploy.md

updates for CGS

Author: msftadam

articles/operator-service-manager/best-practices-onboard-deploy.md

@@ -88,70 +88,6 @@ These five components form a single NSDG. A single NSDG can have multiple NSDVs.
 > [!NOTE]
 > Changes in NFDV shouldn't trigger an NSDV update. The NFDV value should be exposed as a parameter within the CGS, so operators can control what to deploy by using CGVs.
 
-## Configuration Group Schema considerations
-
-We recommend that you always start with a single CGS for the entire NF. If there are site-specific or instance-specific parameters, we still recommend that you keep them in a single CGS. We recommend splitting into multiple CGSs when there are multiple components (rarely NFs, more commonly, infrastructure) or configurations that are shared across multiple NFs. The number of CGSs defines the number of CGVs.
-
-### Scenario
-
-- FluentD, Kibana, and Splunk (common third-party components) are always deployed for all NFs within an NSD. We recommend grouping these components into a single NFDG.
-- NSD has multiple NFs that all share a few configurations (deployment location, publisher name, and a few chart configurations).
-
-In this scenario, we recommend that you use a single global CGS to expose the common NF and third-party component configurations. You can define NF-specific CGS as needed.
-
-### Choose parameters to expose
-
-- CGS should only have parameters that are used by NFs (day 0/N configuration) or shared components.
-- Parameters that are rarely configured should have default values defined.
-- If multiple CGSs are used, we recommend little to no overlap between the parameters. If overlap is required, make sure the parameter names are clearly distinguishable between the CGSs.
-- What can be defined via API (Azure Operator Nexus, Azure Operator Service Manager) should be considered for CGS. As opposed to, for example, defining those configuration values via CloudInit files.
-- When unsure, a good starting point is to expose the parameter and have a reasonable default specified in the CGS. The following example shows the sample CGS and corresponding CGV payloads.
-- A single user-assigned managed identity should be used in all the NF ARM templates and should be exposed via CGS.
-
-CGS payload:
-
-<pre>
-{ 
-  "type": "object", 
-  "properties": { 
-    "abc": { 
-    "type": "integer", 
-    <b>"default": 30</b>
-    }, 
-    "xyz": { 
-    "type": "integer", 
-    <b>"default": 40</b>
-    },
-    "qwe": {
-    "type": "integer" //doesn't have defaults
-    }
-  }
-  "required": "qwe"
-}
-</pre>
-
-Corresponding CGV payload passed by the operator:
-
-<pre>
-{
-"qwe": 20
-}
-</pre>
-
-Resulting CGV payload generated by Azure Operator Service Manager:
-
-<pre>
-{
-"abc": 30,
-"xyz": 40,
-"qwe": 20
-}
-</pre>
-
-## Configuration Group Values considerations
-
-Before you submit the CGV resource creation, you can validate that the schema and values of the underlying YAML or JSON file match what the corresponding CGS expects. To accomplish that, one option is to use the YAML extension for Visual Studio Code.
-
 ## CLI considerations
 
 The Azure Operator Service Manager CLI extension assists with the publishing of NFDs and NSDs. Use this tool as the starting point for creating new NFDs and NSDs. Consider using the CLI to create the initial files. Then edit them to incorporate infrastructure components before you publish.