Skip to content

Commit 3277a5f

Browse files
JillGrant615JillGrant615
authored
Merge pull request #301774 from msftadam/patch-82
Update best-practices-onboard-deploy.md
2 parents 4d907a6 + 36b1eea commit 3277a5f

File tree

4 files changed

+80
-65
lines changed

4 files changed

+80
-65
lines changed

‎articles/operator-service-manager/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,8 @@
1515
items:
1616
- name: Onboard and deploy a Network Function
1717
href: best-practices-onboard-deploy.md
18+
- name: Workload Configuration Management
19+
href: configuration-guide.md
1820
- name: Roles and Interfaces
1921
href: roles-interfaces.md
2022
- name: Helm Package Requirements

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

Lines changed: 0 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -88,70 +88,6 @@ These five components form a single NSDG. A single NSDG can have multiple NSDVs.
8888
> [!NOTE]
8989
> 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.
9090
91-
## Configuration Group Schema considerations
92-
93-
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.
94-
95-
### Scenario
96-
97-
- 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.
98-
- NSD has multiple NFs that all share a few configurations (deployment location, publisher name, and a few chart configurations).
99-
100-
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.
101-
102-
### Choose parameters to expose
103-
104-
- CGS should only have parameters that are used by NFs (day 0/N configuration) or shared components.
105-
- Parameters that are rarely configured should have default values defined.
106-
- 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.
107-
- 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.
108-
- 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.
109-
- A single user-assigned managed identity should be used in all the NF ARM templates and should be exposed via CGS.
110-
111-
CGS payload:
112-
113-
<pre>
114-
{
115-
  "type": "object",
116-
  "properties": {
117-
    "abc": {
118-
    "type": "integer",
119-
    <b>"default": 30</b>
120-
    },
121-
    "xyz": {
122-
    "type": "integer",
123-
    <b>"default": 40</b>
124-
    },
125-
    "qwe": {
126-
    "type": "integer" //doesn't have defaults
127-
    }
128-
  }
129-
  "required": "qwe"
130-
}
131-
</pre>
132-
133-
Corresponding CGV payload passed by the operator:
134-
135-
<pre>
136-
{
137-
"qwe": 20
138-
}
139-
</pre>
140-
141-
Resulting CGV payload generated by Azure Operator Service Manager:
142-
143-
<pre>
144-
{
145-
"abc": 30,
146-
"xyz": 40,
147-
"qwe": 20
148-
}
149-
</pre>
150-
151-
## Configuration Group Values considerations
152-
153-
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.
154-
15591
## CLI considerations
15692

15793
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.

‎articles/operator-service-manager/configuration-guide.md

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
title: Configuration Group Best Practices for Azure Operator Service Manager
3+
description: Learn about configuration group best practices when using Azure Operator Service Manager.
4+
author: msftadam
5+
ms.author: adamdor
6+
ms.date: 06/24/2025
7+
ms.topic: best-practice
8+
ms.service: azure-operator-service-manager
9+
---
10+
11+
# Azure Operator Service Manager best practices for configuration groups
12+
This article provides guidelines that NF vendors, telco operators, and their partners can follow to optimize the design of configuration group schemes and the operation of configuration group values. Keep these practices in mind when you onboard and deploy your NFs.
13+
14+
## Configuration Group Schema considerations
15+
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.
16+
17+
### Scenario
18+
19+
- 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.
20+
- NSD has multiple NFs that all share a few configurations (deployment location, publisher name, and a few chart configurations).
21+
22+
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.
23+
24+
### Choose parameters to expose
25+
26+
- CGS should only have parameters that are used by NFs (day 0/N configuration) or shared components.
27+
- Parameters that are rarely configured should have default values defined.
28+
- 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.
29+
- 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.
30+
- 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.
31+
- A single user-assigned managed identity should be used in all the NF ARM templates and should be exposed via CGS.
32+
33+
CGS payload:
34+
35+
<pre>
36+
{
37+
  "type": "object",
38+
  "properties": {
39+
    "abc": {
40+
    "type": "integer",
41+
    <b>"default": 30</b>
42+
    },
43+
    "xyz": {
44+
    "type": "integer",
45+
    <b>"default": 40</b>
46+
    },
47+
    "qwe": {
48+
    "type": "integer" //doesn't have defaults
49+
    }
50+
  }
51+
  "required": "qwe"
52+
}
53+
</pre>
54+
55+
Corresponding CGV payload passed by the operator:
56+
57+
<pre>
58+
{
59+
"qwe": 20
60+
}
61+
</pre>
62+
63+
Resulting CGV payload generated by Azure Operator Service Manager:
64+
65+
<pre>
66+
{
67+
"abc": 30,
68+
"xyz": 40,
69+
"qwe": 20
70+
}
71+
</pre>
72+
73+
## Configuration Group Values considerations
74+
75+
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.

‎articles/operator-service-manager/index.yml

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -114,8 +114,10 @@ landingContent:
114114
linkLists:
115115
- linkListType: architecture
116116
links:
117-
- text: Best Practices onboard and deploy
117+
- text: Best Practices Onboard and Deploy
118118
url: best-practices-onboard-deploy.md
119+
- text: Workload Configuration Management
120+
url: configuration-guide.md
119121
- linkListType: reference
120122
links:
121123
- text: Glossary

0 commit comments

Comments
 (0)