-
Notifications
You must be signed in to change notification settings - Fork 666
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
[load_minigraph]: Add support to load default_config.json file #1228
Conversation
deb489e
to
cf46687
Compare
cf46687
to
028ee25
Compare
028ee25
to
612d39a
Compare
Veda (Nokia) , @arlakshm - could you please review, thanks. |
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.
Please add unit test for this
@@ -294,6 +294,22 @@ def _get_device_type(): | |||
|
|||
return device_type | |||
|
|||
def _get_hwsku(config_db): |
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 can remove this function here. Same function available in sonic_py_common get_hwsku
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.
get_hwsku
in sonic_py_common
does not support namespaces, it will always connect to the host redis instance.
Also, get_hwsku
in sonic_py_common
will be stuck because it will try to open a new connection to CONFIG_DB.
This can be revisited when sonic_py_common
provides support for namespaces and existing connection.
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.
hwsku is for the whole device, wouldn't getting the hwsku form the host redis work will it change for each namespace/asic ?
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 would be the same hwsku for all namespace/asic. However we can't get it before minigraph.xml is parsed and CONFIG_DB is populated, so calling get_hwsku
from sonic_py_common
beforehand is not possible since CONFIG_DB will be empty.
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.
if config_db is empty then _get_hwsku
won't return the correct hwsku also. I am trying to understand what the difference between _get_hwsku
define here and get_hwsku
in sonic_py_common
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.
_get_hwsku
is called after minigraph.xml is parsed and CONFIG_DB is populated for the corresponding namespace CONFIG_DB initialized at line 1274, _get_hwsku is called at line 1287).
The difference with get_hwsku
from sonic_py_common
is that _get_hwsku
here reuse the existing connection to CONFIG_DB. If we cann get_hwsku
from sonic_py_common
instead it will get stuck because we can't open multiple connections the same time.
npu_id = device_info.get_npu_id_from_name(namespace) | ||
|
||
# load default_config.json file from platform directory | ||
default_config_file = os.path.join('/usr/share/sonic/device/', platform, npu_id, 'default_config.json') |
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.
can you give an example what is present in 'default_config.json'
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.
I added the following example in the description:
{
"DEVICE_METADATA": {
"localhost": {
"instance_name": "ASIC0",
"chassis_db_address" : "240.127.1.1",
"start_chassis_db" : "1",
"asic_id": "06:00.0"
}
}
}
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.
As per PR sonic-net/sonic-buildimage#5991, for VOQ chassis systems the "asic_id" and "instance_name" are configured via minigraph.xml. Will these values from default_config.json be preferred over what is configured through minigraph?
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.
For VOQ chassis systems, we get "start_chassis_db" and "chassis_db_address" from chassisdb.conf from device specific directory (for example: https://github.com/Azure/sonic-buildimage/blob/master/device/arista/x86_64-arista_7800_sup/chassisdb.conf). These are needed before the database service is started in supervisor card. Having these in config_db is of no use. Also, if these are not used in multi-asic we should not have these in default_config.json.
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.
As per PR Azure/sonic-buildimage#5991, for VOQ chassis systems the "asic_id" and "instance_name" are configured via minigraph.xml. Will these values from default_config.json be preferred over what is configured through minigraph?
Both are still valid. If the platform has configuration in default_config.json
it has to be static. If it is present in both files then default_config.json
will override the value configured via minigraph.xml
, which is fine.
The example above is probably incorrect once VoQ config using minigraph.xml is complete (PR5991), however asic_id
is still required in this file as it is platform-dependent.
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.
For VOQ chassis systems, we get "start_chassis_db" and "chassis_db_address" from chassisdb.conf from device specific directory (for example: https://github.com/Azure/sonic-buildimage/blob/master/device/arista/x86_64-arista_7800_sup/chassisdb.conf). These are needed before the database service is started in supervisor card. Having these in config_db is of no use. Also, if these are not used in multi-asic we should not have these in default_config.json.
Right. Actually in the above example only asic_id
is required as it is tied to each asic physically on the hardware. Other configurations can easily be set using minigraph.xml
ad84e94
to
00536b9
Compare
00536b9
to
338d0d1
Compare
I've updated |
42fdb03
to
65d9313
Compare
@vganesan-nokia - please review. |
npu_id = device_info.get_npu_id_from_name(namespace) | ||
|
||
# load default_config.json file from platform directory | ||
default_config_file = os.path.join('/usr/share/sonic/device/', platform, npu_id, 'default_config.json') |
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.
As per PR sonic-net/sonic-buildimage#5991, for VOQ chassis systems the "asic_id" and "instance_name" are configured via minigraph.xml. Will these values from default_config.json be preferred over what is configured through minigraph?
npu_id = device_info.get_npu_id_from_name(namespace) | ||
|
||
# load default_config.json file from platform directory | ||
default_config_file = os.path.join('/usr/share/sonic/device/', platform, npu_id, 'default_config.json') |
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.
For VOQ chassis systems, we get "start_chassis_db" and "chassis_db_address" from chassisdb.conf from device specific directory (for example: https://github.com/Azure/sonic-buildimage/blob/master/device/arista/x86_64-arista_7800_sup/chassisdb.conf). These are needed before the database service is started in supervisor card. Having these in config_db is of no use. Also, if these are not used in multi-asic we should not have these in default_config.json.
fea0649
to
7ccfb2a
Compare
7ccfb2a
to
546e782
Compare
Hi @arlakshm and @vganesan-nokia , Can you approve this review if there is no further comments? |
546e782
to
6cb68c2
Compare
This change add support for a per-device/per-npu default_config.json file that contains platform-specific or hwsku-specific configuration to be used when generating config_db*.json.
6cb68c2
to
1f7de72
Compare
@mlorrillere, @vganesan-nokia This PR sonic-net/sonic-buildimage#7513 adds support to populate the |
I found out about this PR yesterday. We might not need |
This change add support for a per-device/per-npu default_config.json
file that contains platform-specific or hwsku-specific configuration to
be used when generating config_db*.json
An example of such file in a VoQ chassis could be:
- What I did
Added support for a default_config.json file present in platform directory for each NPU and for the host. This file will be loaded when
config load_minigraph
is called.- Why I did it
Some VoQ devices require per-platform/per-NPU configurations to be present in CONFIG_DB.
default_config.json
provides a way for a vendor to give the required initial configuration of a device.- How to verify it
Verified manually on a single and multi-NPU platform with and without a
default_config.json
present in the platform directory.