Upgrade SONiC to Debian Bullseye

[saiarcot895]

Why I did it

In preparation for Debian Bullseye, upgrade SONiC's base system to be based on Bullseye, which was released in August 2021. Major changes from Buster are:

1. Kernel is now based on 5.10.x (currently, official Debian Bullseye is publishing the 5.10.70 kernel)
2. Most Python 2 packages (as well as pip2.7) have been removed from Bullseye. The Python 2 interpreter is still available.

How I did it

The kernel has been upgraded to 5.10.46, and the base system is now based on Bullseye. Containers are still based on Buster.

How to verify it

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106

Description for the changelog

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

[lguohan]

can you resolve the conflict so that the build can proceed?

[saiarcot895]

Conflicts have been resolved. The expectation is that the kvm image should build (none of the containers will get built), broadcom will fail to build (vendor platform modules need changes), mellanox likely will fail to build.

[lguohan]

/azp run

[azure-pipelines]

Pull request contains merge conflicts.

[lguohan]

can you resolve merge conflict, i think the last commit on swss-common is no longer needed.

[saiarcot895]

The libswsscommon, python-swsscommon, and python3-swsscommon packages are all installed on the base image itself, not just in the containers, so I do think they need the Bullseye changes.

Currently, though, the CI run is reporting a test failure in the target/python-wheels/sonic_config_engine-1.0-py3-none-any.whl target:

test_render_template (tests.test_minigraph_case.TestCfgGenCaseInsensitive) ... Traceback (most recent call last):
  File "/sonic/src/sonic-config-engine/tests/../sonic-cfggen", line 443, in <module>
    main()
  File "/sonic/src/sonic-config-engine/tests/../sonic-cfggen", line 405, in main
    env = _get_jinja2_env(paths)
  File "/sonic/src/sonic-config-engine/tests/../sonic-cfggen", line 237, in _get_jinja2_env
    redis_bcc = RedisBytecodeCache(SonicV2Connector(host='127.0.0.1'))
  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1697, in __init__
    for db_name in self.get_db_list():
  File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 1633, in get_db_list
    return _swsscommon.SonicV2Connector_Native_get_db_list(self)
RuntimeError: Sonic database config file doesn't exist at /var/run/redis/sonic-db/database_config.json

[lguohan]

swss-common submodule has already been updated in master branch, you do not need to update it again.

[lguohan]

looks like we still have the sonic-cfggen unit test failure.

[saiarcot895]

Build failures are caused by the sonic-telemetry build/test overwriting /var/run/redis/sonic-db/database_config.json, and then removing the /var/run/redis/sonic-db/ directory. Because the same slave container is used for all of the builds, these changes persist across builds.

The commits responsible for this change are sonic-net/sonic-telemetry@4bb02f5 (overwriting /var/run/redis/sonic-db/database_config.json) and sonic-net/sonic-telemetry@6df988c (removing the /var/run/redis/sonic-db/ directory).

 $ grep database_config.json target/debs/buster/*.log
target/debs/buster/libswsscommon_1.0.0_amd64.deb-install.log:Configuration file '/var/run/redis/sonic-db/database_config.json', does not exist on system.
target/debs/buster/libswsscommon_1.0.0_amd64.deb.log: /usr/bin/install -c -m 644 database_config.json '/sonic/src/sonic-swss-common/debian/tmp/var/run/redis/sonic-db'
target/debs/buster/sonic-telemetry_0.1_amd64.deb.log:sudo cp ./testdata/database_config.json /var/run/redis/sonic-db/

[saiarcot895]

Waiting for #8282 to be merged to fix build issue.

[qiluo-msft]

Could you share more insight why "--net=host is specified twice" ? Maybe we should fix the other place.

[saiarcot895]

Commit c948379 made some changes in files/build_templates/docker_image_ctl.j2. Specifically, it added some code here to explicitly specify which network namespace/topology the container should run in (with the --net= flag): either the host namespace (so that it has all of the host network interfaces accessible within the container), connected to the Docker bridge with veth interfaces (this is the default), or the namespace of another container.

If the container isn't a per-ASIC container (meaning there's only one for the system), then it'll put it in the host namespace. Otherwise, if it's in a multi-ASIC environment and the database container is being started, then that container will be connected in its own network namespace via the default Docker bridge and a veth interface. Otherwise, it'll use the namespace of the database container for that ASIC.

This change also removed all of the explicit --net=host flags specified in the run options for other containers (see the files changed in rules/ directory in that commit), but didn't handle the ones that were defined in the platform/ directory. So I'm replicating the change made in that commit for these other containers.

[lguohan]

i can see the src/sonic-swss-common as a conflict and it blocks the build, can you consider merge your changes in src/sonic-swss-common into the repo so that we won't have such conflict in the future.

[alexrallen]

Hi @saiarcot895 if possible could you please avoid force pushing to this branch?

I know its generally not a problem on feature branches but I am currently working on aligning Mellanox code to this branch in parallel and it would be extremely helpful for me to have a consistent history so that I can better merge in changes from your end as they come in.

Please let me know if there are any problems or anything I can do to help.

[lguohan]

can you fix the lgtm?

[lgtm-com]

This pull request fixes 5 alerts when merging 42855e3 into a8ae39d - view on LGTM.com

fixed alerts:

• 4 for Unused import
• 1 for Syntax error