-
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -242,6 +242,22 @@ def _get_device_type(): | |
|
||
return device_type | ||
|
||
def _get_hwsku(config_db): | ||
""" | ||
Get hwsku from CONFIG_DB | ||
|
||
TODO: move to sonic-py-common | ||
""" | ||
|
||
metadata = config_db.get_table('DEVICE_METADATA') | ||
if metadata and 'localhost' in metadata and 'hwsku' in metadata['localhost']: | ||
return metadata['localhost']['hwsku'] | ||
|
||
click.echo("Could not get the hwsku from CONFIG_DB, setting hwsku to Unknown") | ||
hwsku = 'Unknown' | ||
|
||
return hwsku | ||
|
||
def interface_alias_to_name(config_db, interface_alias): | ||
"""Return default interface name if alias name is given as argument | ||
""" | ||
|
@@ -1284,11 +1300,13 @@ def load_minigraph(db, no_service_restart): | |
log.log_info("'load_minigraph' stopping services...") | ||
_stop_services() | ||
|
||
platform = device_info.get_platform() | ||
|
||
# For Single Asic platform the namespace list has the empty string | ||
# for mulit Asic platform the empty string to generate the config | ||
# for host | ||
namespace_list = [DEFAULT_NAMESPACE] | ||
num_npus = multi_asic.get_num_asics() | ||
num_npus = device_info.get_num_npus() | ||
if num_npus > 1: | ||
namespace_list += multi_asic.get_namespaces_from_linux() | ||
|
||
|
@@ -1309,6 +1327,25 @@ def load_minigraph(db, no_service_restart): | |
else: | ||
command = "{} -H -m --write-to-db {}".format(SONIC_CFGGEN_PATH, cfggen_namespace_option) | ||
clicommon.run_command(command, display_cmd=True) | ||
|
||
if namespace is DEFAULT_NAMESPACE: | ||
npu_id = '' | ||
else: | ||
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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more.
Both are still valid. If the platform has configuration in The example above is probably incorrect once VoQ config using minigraph.xml is complete (PR5991), however There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Right. Actually in the above example only |
||
if os.path.isfile(default_config_file): | ||
command = "{} -j {} {} --write-to-db".format(SONIC_CFGGEN_PATH, default_config_file, cfggen_namespace_option) | ||
clicommon.run_command(command, display_cmd=True) | ||
|
||
hwsku = _get_hwsku(config_db) | ||
# load default_config.json file from hwsku directory | ||
default_config_file = os.path.join('/usr/share/sonic/device/', platform, hwsku, npu_id, 'default_config.json') | ||
if os.path.isfile(default_config_file): | ||
command = "{} -j {} {} --write-to-db".format(SONIC_CFGGEN_PATH, default_config_file, cfggen_namespace_option) | ||
clicommon.run_command(command, display_cmd=True) | ||
|
||
client.set(config_db.INIT_INDICATOR, 1) | ||
|
||
# get the device type | ||
|
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
insonic_py_common
does not support namespaces, it will always connect to the host redis instance.Also,
get_hwsku
insonic_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
fromsonic_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 andget_hwsku
insonic_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
fromsonic_py_common
is that_get_hwsku
here reuse the existing connection to CONFIG_DB. If we cannget_hwsku
fromsonic_py_common
instead it will get stuck because we can't open multiple connections the same time.