-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Persistent loglevel HLD #1041
Persistent loglevel HLD #1041
Conversation
- In case of a warm upgrade, move Logger tables from LOGLEVEL DB to CONFIG DB (with a minor change in the key) and delete LOGLEVEL DB. | ||
- Exposing the "del" function from the swss-common/sonicv2-connector.h to the db migrator. | ||
|
||
(Downgrade will not be supported). |
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.
@yxieca Can we skip downgrade in design? #Closed
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.
Good catch. I don't think the feature has to work for downgrade. However, downgrade is an important operation. It is important to state what would be the behavior for downgrade.
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.
Thanks @yxieca! I am mostly worried the process:
- running with an image with this feature
- downgrade to older image without this feature. By default, the new ConfigDB table is kept and no processes consume it
- upgrade again to an image with this feature: since the config_db.json is carried over to new image, will it be override by "Logger tables from LOGLEVEL 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.
In this case, after step 1: we will have the Logger tables in the CONFIG DB and the LOGLEVEL DB will be empty.
after step 2: the CONFIG DB will contain the old Logger tables and the LOGLEVEL DB will contain new Logger tables with default values.
after step 3: in case of warm-upgrade the content of the Logger tables from the CONFIG DB will be replaced by the content from the LOGLEVEL DB. and the LOGLEVEL 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.
That's nice design consideration. I am looking forward to have this in the design doc itself.
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 just updated it, thanks!
@EdenGri are all code PRs captured in this HLD now? I see new code PRs came recently. Thanks. |
@zhangyanzhao all code PRs captured in the HLD. |
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 **- What I did** Deleted the LOGLEVEL_DB. After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. **- How I did it** Removed the LOGLEVEL_DB from the SONiC code **- How to verify it** All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 - What I did Deleted the LOGLEVEL_DB. After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. - How I did it Removed the LOGLEVEL_DB from the SONiC code - How to verify it All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 **- What I did** Deleted the LOGLEVEL_DB. After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. **- How I did it** Removed the LOGLEVEL_DB from the SONiC code **- How to verify it** All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 - Why I did it After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. - How I did it Removed the LOGLEVEL_DB from the SONiC code - How to verify it All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 **- What I did** Deleted the LOGLEVEL_DB. After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. **- How I did it** Removed the LOGLEVEL_DB from the SONiC code **- How to verify it** All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 - Why I did it After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. - How I did it Removed the LOGLEVEL_DB from the SONiC code - How to verify it All tests were passed
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 #### Why I did it After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. #### How I did it Removed the LOGLEVEL_DB from the SONiC code #### How to verify it All tests were passed
This HLD document is describing the persistent loglevel feature.
Related PRs: