-
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
SONiC FRR Version Upgrade Process Proposal #1438
Conversation
@prsunny @dgsudharsan we would like to follow up on that proposal on the coming TSC meeting. |
tsc/frr/sonic_frr_update_process.md
Outdated
- Responsibility of SONiC FRR release maintainer | ||
- Default 12 months assignment (or until the next upgrade) | ||
- Upgrade FRR version in Nov release, resolve SONiC FRR upgrade integration issues | ||
- If there is a need for May release upgrade due to feature requirement or other reasons, it should be requested in the May release plan and have the same maintainer to handle the second upgrade |
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 am not sure if everyone is on board with this. If for some reason a new feature is integrated in may release by a different contributor, and the different contributor asks for FRR upgrade, it becomes an unplanned activity for the maintainer. Additionally all the patches that are required for newer version plus testing is only familiar to the contributor of the feature. Requesting maintainer to integrate the patches and also qualify it is not ideal.
I would recommend that in such scenarios the effort of migrating the FRR to a newer version will be done by the new requesting contributor, since they can test, port patches and also verify their use case. However following that the maintainer for the FRR will continue to maintain the version, triage issues, etc until November.
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.
Updated process for mid cycle upgrade
tsc/frr/sonic_frr_update_process.md
Outdated
- Build and verify | ||
- Use PTF on local server, – or – | ||
- Manually verify BGP, VRF, IPv4, IPv6 (on sonic-vs.) | ||
- Create PR |
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 would recommend the new PR details clearly like what are the patch changes like, new patches, removed patches, modified patches, etc. This would help in review.
I have defined a template in FRR 8.5.1 PR. May be we can use it? sonic-net/sonic-buildimage#15965
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.
Updated proposal with your template
- Submit fixes to FRR project, submit new FRR topo test to FRR project if there is a gap | ||
- Release maintainer to subscribe to FRR project, and be the FRR Point-of-Contact on behalf of SONiC | ||
- Bring in FRR vulnerabilities and critical patches to SONiC | ||
- If there is a need for May release upgrade due to feature requirement or other reasons, it should be requested in the May release plan and get a consensus with the FRR release maintainer. The person or organization requested the upgrade will be responsible of carrying out FRR upgrade with the same FRR upgrade process described in this proposal. FRR release maintainer will need to work closely with the person or organization to oversee the mid term upgrade, he/she will continue to assume the role of FRR release maintainer until the end of his/her term |
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.
he/she will continue to assume the role of FRR release maintainer until the end of his/her term
-> until the end of regular FRR rebase in November? I believe, irrespective of FRR rebase done as part of the May release or not on a need basis, November SONiC community release will look at the changes in the FRR and rebase as appropriate.
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.
Correct, he/she will continue the role as a release maintainer for FRR until the full 1 year term ends in Nov. Even with May upgrade, the Nov upgrade will be assumed
tsc/frr/sonic_frr_update_process.md
Outdated
- Nov 2021 - Release 8.1.0 (1200+ commits) | ||
- Jul 2021 - Release 8.0.0 (2200+ commits) | ||
|
||
- SONiC to stay out from major/minor releases (x.y) and use patch release (.z) for stability (eg, FRR 8.3.1 instead of 8.3 if it is for 202211 release) |
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.
What's the guideline to rebase with major/minor FRR releases for SONIC community? only the features drive that decision? or we'll always be 2 or 3 releases behind to get some features soak cycles (to get better stability) at the FRR community?
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.
The recommendation is to go with the latest .z release, eg, currently in frrouting.org/release there are 9.0.1 (9/5/23), 8.5.3 (9/4/23), 9.0 (8/4/23), etc, if we are to upgrade now, the guidance is to go with 9.0.1.
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.
OK, for example, let's say 9.0.1 not released, what we have is 9.0 and 8.5.3 releases to choose, which one do we choose here (one release with patch version (previous release 8.5.3) and another one release just with major version(9.0 is the latest release, neither minor nor patch available))?I think, we choose 8.5.3 instead of 9.0, is my understanding correct? please clarify this part in the document.
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.
yes correct, updated in new revision
- Version change in Makefiles | ||
- New Makefiles for new packages (if any) | ||
- Port patches | ||
- Evaluate whether existing FRR patches still applicable to new FRR version |
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.
Is this not a FRR community activity? I believe, we need to worry about SONiC specific changes on top of the FRR community code. Hope we can clearly differentiate the SONiC specific patches vs FRR patches in the file-name or by some other means to smoothen the rebase activity.
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'm trying to understand the issues that we'll encounter if we discard all local FRR code and it's associated patches (present in current SONiC repo) when we migrate (copy new changes from FRR repos) from one version to another FRR release and apply only the SONiC specific changes on top of the FRR code. Am I missing anything basic here?
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.
@venkatmahalingam , the sign-off details in the commit is supposed to have the original credentials (as mentioned in the next line) and should be sufficient to identify whether the changes were committed to sonic-frr or frr. Ideally, frr patches shouldn't require porting when moving to next frr version.
Apply the old patches into new FRR version, and generate new patch files. Keep original credentials
@lguohan can you please help to review this process PR? Thanks. |
@lguohan the proposal has been agreed and approved by the Routing WG and TSC, multiple community members already signoff on github. 2023 OCP SONiC Workgroup also announced this as a 2023 SONiC process achievement, pls merge for the record |
FRR upgrade and patch cadence is largely on need basis in the current SONiC release program. This SONiC FRR upgrade process proposal is to formalize the FRR upgrade cadence and process for future SONiC release programs.