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

[build]: use vfs storage driver to build dockers #2016

Merged
merged 1 commit into from
Sep 5, 2018

Conversation

lguohan
Copy link
Collaborator

@lguohan lguohan commented Sep 5, 2018

seen issues to build dockers using aufs in ubuntu 18.04

Immedidate dockers are exported to docker file and then
imported into sonic image. Thus, whether using vfs or aufs
as the storage driver does not matter for the immediate build.

Signed-off-by: Guohan Lu gulv@microsoft.com

- What I did

- How I did it

- How to verify it
build the image and load to DUT to test.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

seen issues to build dockers using aufs in ubuntu 18.04

Immedidate dockers are exported to docker file and then
imported into sonic image. Thus, whether using vfs or aufs
as the storage driver does not matter for the immediate build.

Signed-off-by: Guohan Lu <gulv@microsoft.com>
@qiluo-msft
Copy link
Collaborator

Do you have a link to the issue?

@lguohan
Copy link
Collaborator Author

lguohan commented Sep 5, 2018

@jleveque
Copy link
Contributor

jleveque commented Sep 5, 2018

Just wanted to note that I also encountered the same build issues on Ubuntu 16.10. This change resolved the issues for me.

@lguohan
Copy link
Collaborator Author

lguohan commented Sep 5, 2018

retest this please

@pavel-shirshov
Copy link
Contributor

pavel-shirshov commented Sep 5, 2018

One note here: vfs doesn't support copy-on-write, so the build process will be slow down and consume more space. Did we try overlay2 fs instead of aufs?

@lguohan
Copy link
Collaborator Author

lguohan commented Sep 5, 2018

overlay2 fs cannot be run on top of overlay2. does not work for me. will check the build time increase.

@lguohan
Copy link
Collaborator Author

lguohan commented Sep 5, 2018

previously,it was 2 hour 30 minutes, now it is 2 hour 49 min.

@lguohan
Copy link
Collaborator Author

lguohan commented Sep 5, 2018

the space should not be a concern as we always build the docker using --squash option, resulting single layer, deep copy should not be a concern here.

@lguohan lguohan merged commit be9f3ad into sonic-net:master Sep 5, 2018
ishidawataru pushed a commit to ishidawataru/sonic-buildimage that referenced this pull request Oct 30, 2018
using native docker is faster than dind dockerd with vfs storage driver

sonic-net#2016

Azure/draft#181

Signed-off-by: Wataru Ishida <ishida@nel-america.com>
ishidawataru pushed a commit to ishidawataru/sonic-buildimage that referenced this pull request Oct 30, 2018
using native docker is faster than dind dockerd with vfs storage driver

sonic-net#2016

Azure/draft#181

Signed-off-by: Wataru Ishida <ishida@nel-america.com>
lguohan pushed a commit that referenced this pull request Nov 2, 2018
…ild (#2215)

using native docker is faster than dind dockerd with vfs storage driver

#2016

Azure/draft#181

Signed-off-by: Wataru Ishida <ishida@nel-america.com>
lguohan added a commit that referenced this pull request Feb 8, 2019
seen issues to build dockers using aufs in ubuntu 18.04

Immedidate dockers are exported to docker file and then
imported into sonic image. Thus, whether using vfs or aufs
as the storage driver does not matter for the immediate build.

Signed-off-by: Guohan Lu <gulv@microsoft.com>
prsunny added a commit that referenced this pull request Nov 19, 2021
c31a362 - 2021-11-18 : [202012][Mux orch] set default as standby, change mux orch priority (#2015) [Prince Sunny]
9a9e8e6 - 2021-11-18 : [202012] Check VS test failure (#2033) [Prince Sunny]
7eaabca - 2021-11-11 : [202012] Fix random failure in PR/CI build. (#2016) [Shilong Liu]
85230fe - 2021-11-04 : [orchagent] Fix group name of port-buffer-drop in flexcounterorch.cpp (#1967) [Junchao-Mellanox]
a55c2ca - 2021-11-03 : [teammgrd]: Handle LAGs cleanup gracefully on Warm/Fast reboot. (#1934) [Nazarii Hnydyn]
taras-keryk pushed a commit to taras-keryk/sonic-buildimage that referenced this pull request Apr 28, 2022
…t#1951)"" (sonic-net#2019)

Refer to sonic-net#1951 for details

The PR sonic-net#1951 was reverted in sonic-net#2016 because it was thought to be causing the build failure in sonic-swss TestWarmReboot UTs. But it seems the failures in TestWarmReboot are still occurring e.g. sonic-net#2017 [build](https://dev.azure.com/mssonic/build/_build/results?buildId=65653&view=logs&s=859b8d9a-8fd6-5a5c-6f5e-f84f1990894e)

I think we can reapply sonic-net#1951 and need to investigate TestWarmReboot tests instability
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants