Separate decoding/updating in update_eeprom_db

[zzhiyuan]

I think it would be best for the syseeprom daemon to publish the
information to the database. However, for now I want to separate the
decoding and the publishing, so that platform plugins can simply
implement get_eeprom_dict and not worry about publishing. Please let me
know why or why not the publishing is not handled in the daemon instead.

Also created symlink for sonic_eeprom that points to the exact same
files in sonic_platform_base/sonic_eeprom.

[jleveque]

@kevinwangsk / @keboliu: Can you please help review?

[keboliu]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

2. Thanks for creating the symbol link, I have planned to do it but not yet.

3. would like to see a whole solution including a PR to the daemon parts.

[zzhiyuan]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

Does this change break platform initialization? It will break "decode-syseeprom --init" because that will call update_eeprom_db, but in sonic_device_util it does not call it with --init. Additionally, might want to consider removing that option with the existence of syseepromd. I've put in a default dict return for eeprom_base.get_eeprom_dict so "decode-syseeprom --init" will not fail, let me know if you'd like this behavior changed.

2. Thanks for creating the symbol link, I have planned to do it but not yet.
3. would like to see a whole solution including a PR to the daemon parts.

I think for the daemon, all that will need to change is call get_eeprom_dict from the plugin, and update the database with the result. I think this is a fundamentally better implementation than having the platform plugins interact with the database. Then after that is implemented, update_eeprom_db can be removed from platform plugin. I'm not sure if I want to take on all of that yet, but this change will allow platform vendors to implement "get_eeprom_dict" without worrying about the database.

[keboliu]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

Does this change break platform initialization? It will break "decode-syseeprom --init" because that will call update_eeprom_db, but in sonic_device_util it does not call it with --init. Additionally, might want to consider removing that option with the existence of syseepromd. I've put in a default dict return for eeprom_base.get_eeprom_dict so "decode-syseeprom --init" will not fail, let me know if you'd like this behavior changed.

I am ok as long as "decode-syseeprom -m" not broken and "--init" option be safely removed.

1. Thanks for creating the symbol link, I have planned to do it but not yet.
2. would like to see a whole solution including a PR to the daemon parts.

I think for the daemon, all that will need to change is call get_eeprom_dict from the plugin, and update the database with the result. I think this is a fundamentally better implementation than having the platform plugins interact with the database. Then after that is implemented, update_eeprom_db can be removed from platform plugin. I'm not sure if I want to take on all of that yet, but this change will allow platform vendors to implement "get_eeprom_dict" without worrying about the database.

IMO if only submit this PR, the daemon will be broken until someone offers a fix, this is what we don't want to see.

[zzhiyuan]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

Does this change break platform initialization? It will break "decode-syseeprom --init" because that will call update_eeprom_db, but in sonic_device_util it does not call it with --init. Additionally, might want to consider removing that option with the existence of syseepromd. I've put in a default dict return for eeprom_base.get_eeprom_dict so "decode-syseeprom --init" will not fail, let me know if you'd like this behavior changed.

I am ok as long as "decode-syseeprom -m" not broken and "--init" option be safely removed.

1. Thanks for creating the symbol link, I have planned to do it but not yet.
2. would like to see a whole solution including a PR to the daemon parts.

I think for the daemon, all that will need to change is call get_eeprom_dict from the plugin, and update the database with the result. I think this is a fundamentally better implementation than having the platform plugins interact with the database. Then after that is implemented, update_eeprom_db can be removed from platform plugin. I'm not sure if I want to take on all of that yet, but this change will allow platform vendors to implement "get_eeprom_dict" without worrying about the database.

IMO if only submit this PR, the daemon will be broken until someone offers a fix, this is what we don't want to see.

With this change, "decode-syseeprom -m" is not broken, and neither is the daemon. The logic for eeprom_tlvinfo has not changed, and eeprom_base now returns a default dict to be put into the database.

[keboliu]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

Does this change break platform initialization? It will break "decode-syseeprom --init" because that will call update_eeprom_db, but in sonic_device_util it does not call it with --init. Additionally, might want to consider removing that option with the existence of syseepromd. I've put in a default dict return for eeprom_base.get_eeprom_dict so "decode-syseeprom --init" will not fail, let me know if you'd like this behavior changed.

I am ok as long as "decode-syseeprom -m" not broken and "--init" option be safely removed.

1. Thanks for creating the symbol link, I have planned to do it but not yet.
2. would like to see a whole solution including a PR to the daemon parts.

I think for the daemon, all that will need to change is call get_eeprom_dict from the plugin, and update the database with the result. I think this is a fundamentally better implementation than having the platform plugins interact with the database. Then after that is implemented, update_eeprom_db can be removed from platform plugin. I'm not sure if I want to take on all of that yet, but this change will allow platform vendors to implement "get_eeprom_dict" without worrying about the database.

IMO if only submit this PR, the daemon will be broken until someone offers a fix, this is what we don't want to see.

With this change, "decode-syseeprom -m" is not broken, and neither is the daemon. The logic for eeprom_tlvinfo has not changed, and eeprom_base now returns a default dict to be put into the database.

I can approve this change ONLY if all "decode-syseeprom" command are all OK, including "-s","-m", "--init", if any one of them be broken, we should either have fix here or in the "decode-syseeprom" scripts. I didn't test the "decode-syseeprom" scripts with your change, so would like to get your confirmation here.

[zzhiyuan]

I don't oppose to refactor syseeprom daemon and the plugin, but some point needs to highlight:

1. please be noted that sonic-utility scripts "decode-syseeprom" also rely on this eeprom plugin, and on some platform it very critical, because during the first-time reboot need to use this script to decode the system eeprom and get the switch base mac, please refer to https://github.com/Azure/sonic-utilities/blob/master/scripts/decode-syseeprom and https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-config-engine/sonic_device_util.py#L68. Which we definitely don't want to break.

Does this change break platform initialization? It will break "decode-syseeprom --init" because that will call update_eeprom_db, but in sonic_device_util it does not call it with --init. Additionally, might want to consider removing that option with the existence of syseepromd. I've put in a default dict return for eeprom_base.get_eeprom_dict so "decode-syseeprom --init" will not fail, let me know if you'd like this behavior changed.

I am ok as long as "decode-syseeprom -m" not broken and "--init" option be safely removed.

1. Thanks for creating the symbol link, I have planned to do it but not yet.
2. would like to see a whole solution including a PR to the daemon parts.

I think for the daemon, all that will need to change is call get_eeprom_dict from the plugin, and update the database with the result. I think this is a fundamentally better implementation than having the platform plugins interact with the database. Then after that is implemented, update_eeprom_db can be removed from platform plugin. I'm not sure if I want to take on all of that yet, but this change will allow platform vendors to implement "get_eeprom_dict" without worrying about the database.

IMO if only submit this PR, the daemon will be broken until someone offers a fix, this is what we don't want to see.

With this change, "decode-syseeprom -m" is not broken, and neither is the daemon. The logic for eeprom_tlvinfo has not changed, and eeprom_base now returns a default dict to be put into the database.

I can approve this change ONLY if all "decode-syseeprom" command are all OK, including "-s","-m", "--init", if any one of them be broken, we should either have fix here or in the "decode-syseeprom" scripts. I didn't test the "decode-syseeprom" scripts with your change, so would like to get your confirmation here.

It should not break any of decode-syseeprom functions. However I have only tested on Arista platforms, I think it would be worthwhile for you to confirm that this is fine in ONIE platforms, but from looking at the changes there should not be any behavioral differences.

[rustiqly]

This PR has been open since July 2019 (~7 years) and has merge conflicts with the current codebase. The eeprom infrastructure has been significantly reworked since then — the files this PR modifies have changed substantially.

Given the age and conflicts, this is likely no longer mergeable without a complete rewrite against current master. Suggesting closure as stale. If the underlying improvement (separating decoding from DB publishing) is still desired, it would be better addressed in a fresh PR against the current codebase.