Skip to content

Commit 160b37c

Browse files
authored
Update configuration-guide.md
updates for JSON
1 parent 428cd8c commit 160b37c

File tree

1 file changed

+66
-1
lines changed

1 file changed

+66
-1
lines changed

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

Lines changed: 66 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,9 +8,74 @@ ms.topic: best-practice
88
ms.service: azure-operator-service-manager
99
---
1010

11-
# Azure Operator Service Manager best practices for configuration groups
11+
# Workload configuration management
1212
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.
1313

14+
## What is JSON schema
15+
JSON Schema is an IETF standard providing a format for what JSON data is required for a given application and how to interact with it. Applying such standards for a JSON document lets you enforce consistency and data validity across JSON data
16+
17+
### Where is JSON schema used
18+
* AOSM service uses JSON schema notation as a meta-schema within CGS `ConfigurationGroupSchemaPropertiesFormat` object `schemaDefinition` properties. For more information on CG schema see the [swagger documentation](https://learn.microsoft.com/en-us/rest/api/hybridnetwork/configuration-group-schemas/create-or-update?view=rest-hybridnetwork-2023-09-01&tabs=HTTP#configurationgroupschemapropertiesformat).
19+
* AOSM service allows the designer and publisher to specify the JSON schema where operator must provide data (JSON Values) when instantiating an SNS/NF.
20+
* AOSM service allows the meta-schema properties be optional or required. Where a property is marked required, it must be specified in the values Json.
21+
22+
### What JSON keywords are supported
23+
For the CG meta-schema, AOSM implements supports for JSON standard keywoards on a type by type basis.
24+
25+
* For object types, keyword supported is limited by filter policy. See JSON Schema - [object](https://json-schema.org/understanding-json-schema/reference/object)
26+
* For string types, keyword support is not limited or filtered. See JSON Schema - [string](https://json-schema.org/understanding-json-schema/reference/string)
27+
* For numeric types, keyword support is not limited or filtered. See JSON Schema - [numeric](https://json-schema.org/understanding-json-schema/reference/numeric)
28+
29+
## Optional and Required fields
30+
A property can be declared as an optional field if publisher/designer explicitly provides a required section and the required section does not contain the property that needs to be optional. An optional property can also have defaults to it. A property is required if the designer/publisher has not specified the required section and the property does not have defaults.
31+
32+
```json
33+
{
34+
"type": "object",
35+
"properties": {
36+
"abc": {
37+
"type": "integer",
38+
"default": 30
39+
},
40+
"xyz": {
41+
"type": "string",
42+
"default": "abc123"
43+
}
44+
}
45+
"required": ["abc"]
46+
}
47+
```
48+
49+
50+
## Defaults Values in JSON Schema
51+
AOSM service implements a custom method of default value handling, which can be provided for optional properties. When the publisher or designer define default values in CG meta-schema, AOSM uses these value for properties that are missing or undefined in the input CG values data. AOSM service validator logic essemtially hydrates the CG value input with default where no optional value has been provided by operator.
52+
53+
### How to define defaults
54+
Defaults must be specified either inside properties or inside items of array. The following example demonstrates defaults with integer and strying property types.
55+
56+
```json
57+
{
58+
"type": "object",
59+
"properties": {
60+
"abc": {
61+
"type": "integer",
62+
"default": 30
63+
},
64+
"xyz": {
65+
"type": "string",
66+
"default": "abc123"
67+
}
68+
}
69+
}
70+
```
71+
72+
### Rules for defining defaults
73+
A field which has a “default” should not be defined in the required section of the schema. During the validation process (CGV creation and NF creation), if a property is missing or undefined in the input data, the validator will assign values from default keyword in the schemas of properties and items (when it is the array of schemas) to the missing properties and items.
74+
75+
Defaults are evaluated in top-down order from where the property is seen. If a property exists in input Json, only its child properties will be evaluated for defaults. If the property does not exist in input Json, then its default will be evaluated along with any child properties which do not exist in the defaults of the property.
76+
77+
If default for an object is not specified and the input json does not contain the object key, then no defaults which are provided under the properties of the object are evaluated.
78+
1479
## Configuration Group Schema considerations
1580
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.
1681

0 commit comments

Comments
 (0)