Skip to content
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

Merged
merged 5 commits into from
Dec 5, 2023

Conversation

adyeung
Copy link
Collaborator

@adyeung adyeung commented Aug 2, 2023

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.

@liat-grozovik
Copy link
Collaborator

@prsunny @dgsudharsan we would like to follow up on that proposal on the coming TSC meeting.
As the FRR maintainers appreciate to get your feedback and ensure you are ok and have no questions. if so, lets raise and try to close.

- 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
Copy link
Contributor

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.

Copy link
Collaborator Author

@adyeung adyeung Aug 29, 2023

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

- Build and verify
- Use PTF on local server, – or –
- Manually verify BGP, VRF, IPv4, IPv6 (on sonic-vs.)
- Create PR
Copy link
Contributor

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

Copy link
Collaborator Author

@adyeung adyeung Aug 29, 2023

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
Copy link
Collaborator

@venkatmahalingam venkatmahalingam Oct 2, 2023

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.

Copy link
Collaborator Author

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

- 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)
Copy link
Collaborator

@venkatmahalingam venkatmahalingam Oct 2, 2023

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

@venkatmahalingam venkatmahalingam Oct 2, 2023

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

@venkatmahalingam venkatmahalingam Oct 2, 2023

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.

Copy link
Collaborator

@venkatmahalingam venkatmahalingam Oct 2, 2023

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?

Copy link
Contributor

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

@skg-net skg-net assigned skg-net and unassigned skg-net Oct 3, 2023
@skg-net skg-net self-requested a review October 3, 2023 07:02
skg-net
skg-net previously approved these changes Oct 3, 2023
@zhangyanzhao
Copy link
Collaborator

@lguohan can you please help to review this process PR? Thanks.

@adyeung
Copy link
Collaborator Author

adyeung commented Oct 26, 2023

@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

@lguohan lguohan merged commit 38f1090 into sonic-net:master Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants