-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Upgrade docker-sonic-vs and docker-syncd-vs to Bullseye #13294
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
Conversation
Signed-off-by: Saikrishna Arcot <[email protected]>
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
There is an issue with Docker's overlay2 storage driver when not using native diffs (and thus falling back to naive diff mode), which is the case in the CI builds. The way the naive diff mode detects changes is by comparing the file size and comparing the timestamps (specifically, I believe it's the modification timestamp), and if there's a change there, then it's considered a change that needs to be recorded as part of that layer. The problem is that with the code being added in the patch, the file size remains the same, and the timestamp of binary files appear to be the same timestamp as the changelog entry (likely for reproducible build purposes). The file size remains the same likely due to extra padding within the file introduced by relro. Because of this, Docker doesn't detect this file has changed, and doesn't save the new file as part of this layer. To work around this, create a new changelog entry (with a new version as well) with a new timestamp. This will result in the binary files having a different timestamp, and thus will get saved by Docker as part of that layer. Signed-off-by: Saikrishna Arcot <[email protected]>
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run Azure.sonic-buildimage |
/AzurePipelines run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
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.
Not tested, but it looks good to me, thanks!
@@ -2,9 +2,7 @@ | |||
|
|||
DOCKER_SONIC_VS = docker-sonic-vs.gz | |||
$(DOCKER_SONIC_VS)_PATH = $(PLATFORM_PATH)/docker-sonic-vs | |||
$(DOCKER_SONIC_VS)_DEPENDS += $(SWSS) \ |
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.
Curious why $(SWSS)
is removed here? Is it because it's now taken care of in the addition on line 46?
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, docker-sonic-vs
will be based on top of docker-swss-layer-bullseye
, which will contain SWSS.
The initial intention of that layer was to save space by having SWSS be in a single layer and then other containers can be built on top of this layer. In this case, since docker-sonic-vs
won't actually be part of the SONiC image, there's effectively no impact.
With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]>
@@ -24,10 +24,6 @@ RUN apt-get install -y net-tools \ | |||
python-ply \ | |||
libqt5core5a \ | |||
libqt5network5 \ | |||
libboost-program-options1.71.0 \ | |||
libboost-serialization1.71.0 \ |
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.
Hi @saiarcot895 , why removed libboost package?
sonic-swss/sonic-sairedis pipelines are affected. Because they install swsscommon in docker-sonic-vs docker.
https://dev.azure.com/mssonic/build/_build/results?buildId=238973&view=logs&jobId=83516c17-6666-5250-abde-63983ce72a49&j=ec04b24c-02f9-5d3d-ea93-ae01af596cc2&t=efc0b8f4-1762-5832-d518-167f53484867
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.
https://github.com/sonic-net/sonic-swss-common/blob/e3d9024602847d5bb41e14f153099431ef35f291/debian/control#L5
swss-common still depends on libboost1.71.
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.
Boost 1.71 is not available in Bullseye, Bullseye has Boost 1.74. Because of this (and other differences), the pipelines for swss-common, swss, and sairedis were bound to fail. In addition, the base layer of this container has changed; it's now based on swss-layer-bullseye (which will contain both swss and swsscommon).
As for the pipeline breakages, I've already opened sonic-net/sonic-swss-common#716 to fix it for swss-common. Once that is fixed, I should be able to fix it for sairedis (sonic-net/sonic-sairedis#1225) and swss (PR to be opened).
With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]>
* Update build pipeline to build for Bullseye With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]> * Update .NET core repo URL Signed-off-by: Saikrishna Arcot <[email protected]> * Fix dependencies Signed-off-by: Saikrishna Arcot <[email protected]> * Fix up Dockerfile Signed-off-by: Saikrishna Arcot <[email protected]> --------- Signed-off-by: Saikrishna Arcot <[email protected]>
* Update build pipeline to build for Bullseye With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <[email protected]> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <[email protected]> --------- Signed-off-by: Saikrishna Arcot <[email protected]>
* Update build pipeline to build for Bullseye With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <[email protected]> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <[email protected]> --------- Signed-off-by: Saikrishna Arcot <[email protected]>
* Update build pipeline to build for Bullseye With the merge of sonic-net/sonic-buildimage#13294, docker-sonic-vs is now based on Bullseye. Switch to building for Bullseye to match that change. Signed-off-by: Saikrishna Arcot <[email protected]> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <[email protected]> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <[email protected]> --------- Signed-off-by: Saikrishna Arcot <[email protected]> Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Saikrishna Arcot [email protected]
Why I did it
Fixes #11706
How I did it
Upgrade docker-sonic-vs, docker-syncd-vs, and iproute2 to Bullseye/Bullseye versions.
Submodules that use docker-sonic-vs for their CI will need to be updated to pull/install Bullseye packages instead of Buster packages.
How to verify it
Which release branch to backport (provide reason below if selected)
Description for the changelog
Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)