Debian Trixie migration for sonic-mgmt-common#211
Debian Trixie migration for sonic-mgmt-common#211amrutasali wants to merge 3 commits intosonic-net:masterfrom
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Amruta Sali <amruta_sali@dell.com>
Signed-off-by: Amruta Sali <amruta_sali@dell.com>
amrutasali
force-pushed
the
trixie_migration_for_sonic_mgmt_common
branch
from
be6236e to
9aa7f8b
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR updates sonic-mgmt-common build and CI configuration to support Debian Trixie, aligning with the broader SONiC Trixie migration so downstream projects (notably sonic-mgmt-framework) can build and run on the new distro.
Changes:
- Switch Azure Pipelines build container and artifact paths from Bookworm to Trixie, including installing libpcre3 packages required by libyang.
- Bump the module Go version to Go 1.24.4.
- Adjust translib YGOT binding generation to account for Go 1.24+ vendoring behavior.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
azure-pipelines.yml |
Migrates pipeline container/artifact paths to Trixie and installs additional Debian dependencies. |
go.mod |
Updates declared Go version for the module. |
translib/Makefile |
Attempts to patch vendoring metadata to allow go run of vendored ygot generator under Go 1.24+. |
cvl/cvl.go |
Minor logging call adjustment while parsing schema files. |
| # Go 1.24+ changed 'go mod vendor' to only include packages directly | ||
| # imported by the module. The ygot tool packages and their dependencies | ||
| # are used by 'go run' below but not directly imported, so they are no | ||
| # longer vendored automatically. Add them to vendor/modules.txt. | ||
| @grep -q 'github.com/openconfig/ygot/ygen' $(TOPDIR)/vendor/modules.txt 2>/dev/null || \ | ||
| ( echo "github.com/openconfig/gnmi/ctree" >> $(TOPDIR)/vendor/modules.txt && \ | ||
| echo "github.com/openconfig/gnmi/errlist" >> $(TOPDIR)/vendor/modules.txt && \ | ||
| echo "github.com/openconfig/gnmi/proto/gnmi" >> $(TOPDIR)/vendor/modules.txt && \ | ||
| echo "github.com/openconfig/ygot/genutil" >> $(TOPDIR)/vendor/modules.txt && \ | ||
| echo "github.com/openconfig/ygot/generator" >> $(TOPDIR)/vendor/modules.txt && \ | ||
| echo "github.com/openconfig/ygot/ygen" >> $(TOPDIR)/vendor/modules.txt ) | ||
| $(GO) run \ | ||
| --mod=vendor \ | ||
| $(TOPDIR)/vendor/github.com/openconfig/ygot/generator/generator.go \ |
There was a problem hiding this comment.
Editing vendor/modules.txt by appending raw package paths is very likely to produce an invalid or misleading modules.txt, because entries are expected to be grouped under a corresponding "# " header (and optionally "## explicit"). Appending at EOF can associate these packages with the wrong module header or leave them without one, and it also makes the build non-reproducible by mutating generated vendoring output during the build. Prefer making vendoring include the needed tool packages (e.g., add a build-tagged tools file with blank imports for the ygot generator/ygen deps and regenerate vendor), rather than patching modules.txt in-place.
| # Go 1.24+ changed 'go mod vendor' to only include packages directly | |
| # imported by the module. The ygot tool packages and their dependencies | |
| # are used by 'go run' below but not directly imported, so they are no | |
| # longer vendored automatically. Add them to vendor/modules.txt. | |
| @grep -q 'github.com/openconfig/ygot/ygen' $(TOPDIR)/vendor/modules.txt 2>/dev/null || \ | |
| ( echo "github.com/openconfig/gnmi/ctree" >> $(TOPDIR)/vendor/modules.txt && \ | |
| echo "github.com/openconfig/gnmi/errlist" >> $(TOPDIR)/vendor/modules.txt && \ | |
| echo "github.com/openconfig/gnmi/proto/gnmi" >> $(TOPDIR)/vendor/modules.txt && \ | |
| echo "github.com/openconfig/ygot/genutil" >> $(TOPDIR)/vendor/modules.txt && \ | |
| echo "github.com/openconfig/ygot/generator" >> $(TOPDIR)/vendor/modules.txt && \ | |
| echo "github.com/openconfig/ygot/ygen" >> $(TOPDIR)/vendor/modules.txt ) | |
| $(GO) run \ | |
| --mod=vendor \ | |
| $(TOPDIR)/vendor/github.com/openconfig/ygot/generator/generator.go \ | |
| # Run the ygot generator through normal module resolution instead of | |
| # mutating vendor/modules.txt at build time. Editing vendor metadata | |
| # in-place is not reproducible and can leave modules.txt invalid. | |
| $(GO) run \ | |
| --mod=mod \ | |
| github.com/openconfig/ygot/generator \ |
| ) | ||
|
|
||
| go 1.21 | ||
| go 1.24.4 |
There was a problem hiding this comment.
The go.mod "go" directive typically only accepts a major.minor language version (e.g., "go 1.24"); using a patch version like "1.24.4" can make go.mod parsing fail. If you need to pin the toolchain patch level, keep "go 1.24" and add a separate "toolchain go1.24.4" directive.
| go 1.24.4 | |
| go 1.24 | |
| toolchain go1.24.4 |
|
|
||
| - script: | | ||
| sudo pip3 install ../target/python-wheels/bookworm/sonic_yang_models-1.0-py3-none-any.whl | ||
| sudo pip3 install ../target/python-wheels/trixie/sonic_yang_models-1.0-py3-none-any.whl |
There was a problem hiding this comment.
This pip install uses a hard-coded wheel filename (sonic_yang_models-1.0-py3-none-any.whl) but the downloaded artifact pattern is sonic_yang_models*.whl. If the wheel version/build tag changes, the pipeline will fail even though the artifact was downloaded. Consider installing via a wildcard/path discovery (or using the exact filename produced by the buildimage pipeline) to keep this step resilient to version bumps.
| sudo pip3 install ../target/python-wheels/trixie/sonic_yang_models-1.0-py3-none-any.whl | |
| set -- ../target/python-wheels/trixie/sonic_yang_models*.whl | |
| if [ "$1" = "../target/python-wheels/trixie/sonic_yang_models*.whl" ]; then | |
| echo "No sonic_yang_models wheel found under ../target/python-wheels/trixie/" | |
| exit 1 | |
| fi | |
| if [ "$#" -ne 1 ]; then | |
| echo "Expected exactly one sonic_yang_models wheel, found $#" | |
| ls -1 ../target/python-wheels/trixie/sonic_yang_models*.whl | |
| exit 1 | |
| fi | |
| sudo pip3 install "$1" |
Why I did it -
Required for sonic-net/SONiC#2169 , sonic-mgmt-common is a dependency for sonic-mgmt-framework
How I did it -
Updated the package build configuration to support Trixie distro. Key changes include:
Updated Azure Pipelines to use sonic-slave-trixie container
Added libpcre3 dependencies (not available in Trixie repos)
Bumped Go version to 1.24.4 to align with Trixie's provided version
Fixed Go 1.24+ vendor module requirements for ygot tool
How to verify it -
The sonic-mgmt-framework container builds successfully under BLDENV=trixie which in turn builds sonic-mgmt-common(the .deb was correctlt paced in target/debs/trixie). Installed sonic-mgmt-framework container on a recent SONiC image and verified that the docker OS distribution shows Trixie and basic curl test on REST server hosted within the docker works fine. Also executed the pipeline tests locally.
Note:
Dependent/Related PRs:
sonic-net/sonic-buildimage#26548
sonic-net/sonic-mgmt-framework#158