-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Upgrade docker-sonic-vs and docker-syncd-vs to Bullseye #13294
Conversation
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
/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 <sarcot@microsoft.com>
/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 <sarcot@microsoft.com>
@@ -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 <sarcot@microsoft.com>
* 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 <sarcot@microsoft.com> * Update .NET core repo URL Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> * Fix dependencies Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> * Fix up Dockerfile Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> --------- Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
* 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 <sarcot@microsoft.com> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> --------- Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
* 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 <sarcot@microsoft.com> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> --------- Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
* 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 <sarcot@microsoft.com> * Reduce dependency list to just development packages Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> * Update .NET repo URL and package name Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> --------- Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com> Signed-off-by: Ze Gan <ganze718@gmail.com>
Signed-off-by: Saikrishna Arcot sarcot@microsoft.com
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)