sonic-buildimage/rules/config
Kalimuthu-Velappan 7d2ebf8116
[build]: support for DPKG local caching (#4117)
DPKG caching framework provides the infrastructure to cache the sonic module/target .deb files into a local cache by tracking the target dependency files.SONIC build infrastructure is designed as a plugin framework where any new source code can be easily integrated into sonic as a module and that generates output as a .deb file. The source code compilation of a module is completely independent of other modules compilation. Inter module dependency is resolved through build artifacts like header files, libraries, and binaries in the form of Debian packages. For example module A depends on module B. While module A is being built, it uses B's .deb file to install it in the build docker.

The DPKG caching framework provides an infrastructure that caches a module's deb package and restores it back to the build directory if its dependency files are not modified. When a module is compiled for the first time, the generated deb package is stored at the DPKG cache location. On the subsequent build, first, it checks the module dependency file modification. If none of the dependent files is changed, it copies the deb package from the cache location, otherwise, it goes for local compilation and generates the deb package. The modified files should be checked-in to get the newer cache deb package.

This provides a huge improvement in build time and also supports the true incremental build by tracking the dependency files.

- How I did it
It takes two global arguments to enable the DPKG caching, the first one indicates the caching method and the second one describes the location of the cache.
SONIC_DPKG_CACHE_METHOD=cache
SONIC_DPKG_CACHE_SOURCE=

    where  SONIC_DPKG_CACHE_METHOD - Default method is 'cache' for deb package caching
                            none:     no caching
                            cache:    cache from local directory
Dependency file tracking:
Dependency files are tracked for each target in two levels.
1. Common make infrastructure files - rules/config, rules/functions, slave.mk etc.
2. Per module files - files which are specific to modules, Makefile, debian/rules, patch files, etc.

    For example: dependency files for Linux Kernel - src/sonic-linux-kernel,

            SPATH       := $($(LINUX_HEADERS_COMMON)_SRC_PATH)
            DEP_FILES   := $(SONIC_COMMON_FILES_LIST) rules/linux-kernel.mk rules/linux-kernel.dep
            DEP_FILES   += $(SONIC_COMMON_BASE_FILES_LIST)
            SMDEP_FILES := $(addprefix $(SPATH)/,$(shell cd $(SPATH) && git ls-files))

            DEP_FLAGS := $(SONIC_COMMON_FLAGS_LIST) \
                         $(KERNEL_PROCURE_METHOD) $(KERNEL_CACHE_PATH)

            $(LINUX_HEADERS_COMMON)_CACHE_MODE  := GIT_CONTENT_SHA
            $(LINUX_HEADERS_COMMON)_DEP_FLAGS   := $(DEP_FLAGS)
            $(LINUX_HEADERS_COMMON)_DEP_FILES   := $(DEP_FILES)
            $(LINUX_HEADERS_COMMON)_SMDEP_FILES := $(SMDEP_FILES)
            $(LINUX_HEADERS_COMMON)_SMDEP_PATHS := $(SPATH)
Cache file tracking:
The Cache file is a compressed TAR ball of a module's target DEB file and its derived-target DEB files.
The cache filename is formed with the following format

    FORMAT:
            <module deb filename>.<24 byte of DEP SHA hash >-<24 byte of MOD SHA hash>.tgz
            Eg:
              linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u3_all.deb-23658712fd21bb776fa16f47-c0b63ef593d4a32643bca228.tgz

            < 24-byte DEP SHA value > - the SHA value is derived from all the dependent packages.
            < 24-byte MOD SHA value > - the SHA value is derived from either of the following.
                    GIT_COMMIT_SHA  - SHA value of the last git commit ID if it is a submodule
                    GIT_CONTENT_SHA - SHA value is generated from the content of the target dependency files.
Target Specific rules:
Caching can be enabled/disabled on a global level and also on the per-target level.

            $(addprefix $(DEBS_PATH)/, $(SONIC_DPKG_DEBS)) : $(DEBS_PATH)/% : .platform $$(addsuffix -install,$$(addprefix $(DEBS_PATH)/,$$($$*_DEPENDS))) \
                    $(call dpkg_depend,$(DEBS_PATH)/%.dep )
            $(HEADER)


            # Load the target deb from DPKG cache
            $(call LOAD_CACHE,$*,$@)


            # Skip building the target if it is already loaded from cache
            if [ -z '$($*_CACHE_LOADED)' ] ; then

                  .....
                 # Rules for Generating the target DEB file.
                  .....

                  # Save the target deb into DPKG cache
                  $(call SAVE_CACHE,$*,$@)
            fi


            $(FOOTER)


    The make rule-'$(call dpkg_depend,$(DEBS_PATH)/%.dep )' checks for target dependency file modification. If it is newer than the target, it will go for re-generation of that target.

    Two main macros 'LOAD_CACHE' and 'SAVE_CACHE' are used for loading and storing the cache contents.
    The 'LOAD_CACHE' macro is used to load the cache file from cache storage and extracts them into the target folder. It is done only if target dependency files are not modified by checking the GIT file status, otherwise, cache loading is skipped and full compilation is performed.
    It also updates the target-specific variable to indicate the cache is loaded or not.
    The 'SAVE_CACHE' macro generates the compressed tarball of the cache file and saves them into cache storage. Saving into the cache storage is protected with a lock.
- How to verify it

    The caching functionality is verified by enabling it in Linux kernel submodule.
    It uses the cache directory as 'target/cache' where Linux cache file gets stored on the first-time build and it is picked from the cache location during the subsequent clean build.
- Description for the changelog
The DPKG caching framework provides the infrastructure to save the module-specific deb file to be cached by tracking the module's dependency files.
If the module's dependency files are not changed, it restores the module deb files from the cache storage.

- Description for the changelog

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

DOCUMENT PR:

           https://github.com/Azure/SONiC/pull/559
2020-03-11 20:04:52 -07:00

125 lines
5.4 KiB
Plaintext

###############################################################################
## Configuration parameters for SONiC build system
###############################################################################
# SONIC_CONFIG_PRINT_DEPENDENCIES - show dependencies for each invoked target.
# Before executing rule for each target its dependencies are printed to console.
# Uncomment next line to enable:
# SONIC_CONFIG_PRINT_DEPENDENCIES = y
# SONIC_CONFIG_BUILD_JOBS - set number of jobs for parallel build.
# Corresponding -j argument will be passed to make command inside docker
# container.
SONIC_CONFIG_BUILD_JOBS = 1
# SONIC_CONFIG_MAKE_JOBS - set number of parallel make jobs per package.
# Corresponding -j argument will be passed to make/dpkg commands that build separate packages
SONIC_CONFIG_MAKE_JOBS = $(shell nproc)
# SONIC_USE_DOCKER_BUILDKIT - use docker buildkit for build.
# If set to y SONiC build system will set environment variable DOCKER_BUILDKIT=1
# to enable docker buildkit.
# This options will speed up docker image build time.
# NOTE: SONIC_USE_DOCKER_BUILDKIT will produce larger installable SONiC image
# because of a docker bug (more details: https://github.com/moby/moby/issues/38903)
# SONIC_USE_DOCKER_BUILDKIT = y
# SONIC_CONFIG_USE_NATIVE_DOCKERD_FOR_BUILD - use native dockerd for build.
# If set to y SONiC build container will use native dockerd instead of dind for faster build
# SONIC_CONFIG_USE_NATIVE_DOCKERD_FOR_BUILD = y
# SONIC_CONFIG_ENABLE_COLORS - enable colored output in build system.
# Comment next line to disable:
# SONIC_CONFIG_ENABLE_COLORS = y
# DEFAULT_USERNAME - default username for installer build
DEFAULT_USERNAME = admin
# DEFAULT_PASSWORD - default password for installer build
DEFAULT_PASSWORD = YourPaSsWoRd
# ENABLE_DHCP_GRAPH_SERVICE - specify the source of minigraph to generate configuration file.
# If set to y SONiC will get the minigraph from graph service. Graph service URL need to be
# passed through DHCP option 225.
# If not set (default behavior) the default minigraph built into the image will be used.
# ENABLE_DHCP_GRAPH_SERVICE = y
# ENABLE_ZTP - installs Zero Touch Provisioning support.
# ENABLE_ZTP = y
# SHUTDOWN_BGP_ON_START - if set to y all bgp sessions will be in admin down state when
# bgp service starts.
# SHUTDOWN_BGP_ON_START = y
# ENABLE_PFCWD_ON_START - if set to y PFC Watchdog (PFCWD) will be enabled all server-facing ports
# by default for TOR switch
# ENABLE_PFCWD_ON_START = y
# INSTALL_DEBUG_TOOLS - installs debugging tools in baseline docker
# Uncomment next line to enable:
# INSTALL_DEBUG_TOOLS = y
# SONIC_ROUTING_STACK - specify the routing-stack being elected to drive SONiC's control-plane.
# Supported routing stacks on SONiC are:
# routing-stacks: quagga, frr.
SONIC_ROUTING_STACK = frr
# ENABLE_SYNCD_RPC - build docker-syncd with rpc packages for testing purposes.
# Uncomment to enable:
# ENABLE_SYNCD_RPC = y
# Enable Origanization Extensions - Specific to the deployment scenarios of the Organization
ENABLE_ORGANIZATION_EXTENSIONS = y
# Debugging option allows sonic debian packages to get built including symbols
# information. Profiling option, disables compiler optimizations (-O0) as well
# as includes symbols information. Given that 'profiling' option is a superset
# of 'debugging' one, user should only enable either one option or the other --
# if both options are enabled, the 'profiling' one will prevail.
#SONIC_DEBUGGING_ON = y
#SONIC_PROFILING_ON = y
# ENABLE_SYSTEM_TELEMETRY - build docker-sonic-telemetry for system telemetry support
ENABLE_SYSTEM_TELEMETRY = y
# DEFAULT_KERNEL_PROCURE_METHOD - default method for obtaining kernel
# build: build kernel from source
# download: download pre-built kernel from Azure storage.
DEFAULT_KERNEL_PROCURE_METHOD = build
# FRR user and group id values. These only take effect when SONIC_ROUTING_STACK is frr.
# Note: these values match the admin uid/gid of the host's admin account. If these values
# change and user doesn't want the frr uid/gid to potentially match a random user on the
# host, then either the appropriate account and group will need to be created on the host
# manually or changes need to be made when the image is built to create the account and
# group during installation.
FRR_USER_UID = 300
FRR_USER_GID = 300
# DPKG cache allows the .deb files to be stored in the cache path. This allows the submodules
# package to be cached and restored back if its commit hash is not modified and its dependencies are not modified.
# SONIC_DPKG_CACHE_METHOD - Default method of deb package caching
# none : no caching
# rwcache : Use cache if exists else build the source and update the cache
# wcache : Dont use the cache and just build the source and update the cache
# rcache : Use cache if exists, but dont update the cache
# cache : Same as rwcache
# SONIC_DPKG_CACHE_SOURCE - Stores the cache location details
SONIC_DPKG_CACHE_METHOD ?= none
SONIC_DPKG_CACHE_SOURCE ?= /var/cache/sonic/artifacts
# Default VS build memory preparation
DEFAULT_VS_PREPARE_MEM = yes
# ENABLE_SYSTEM_SFLOW - build docker-sonic-sflow for sFlow support
ENABLE_SFLOW = y
# ENABLE_MGMT_FRAMEWORK - build docker-sonic-mgt-framework for CLI and REST server support
ENABLE_MGMT_FRAMEWORK = y
# ENABLE_RESTAPI - build docker-sonic-restapi for configuring the switch using REST APIs
ENABLE_RESTAPI = n
# ENABLE_NAT - build docker-sonic-nat for nat support
ENABLE_NAT = y