[SmartSwitch] Mask dash-ha service when dash-ha is not enabled#5
[SmartSwitch] Mask dash-ha service when dash-ha is not enabled#5
Conversation
Signed-off-by: Connor Roos <[email protected]>
vivekrnv
left a comment
There was a problem hiding this comment.
LGTM, Please verify if HA is not started in NPU or DPU by default.
@tirupatihemanth Please review
I added to the comment that the service is now masked by default, so it can't even be started manually if it was not built with dash-ha |
|
dash-ha is always enabled during the build by default, https://github.com/sonic-net/sonic-buildimage/blob/6733121c6148eaa8f566c1bfe8e64c7a14534e70/rules/config#L179 Even for NPU or DPU, the container is always built and is part of image Change you are trying to make would set the feature status to be disabled (and masked because of that) by default even when the container is included in the image. Please update the description. |
|
Agree with @vivekrnv, The dash ha container is always part of the image. With these changes it is always disabled by default. Users who would like to use the feature can enable it explicitly during runtime. |
…net#25643) * [build] Add build timing report and dependency analysis tools Add three scripts for build performance instrumentation: - scripts/build-timing-report.sh: Parse per-package timing from build logs (HEADER/FOOTER timestamps), generate sorted duration table, phase breakdown, parallelism timeline, and CSV export. - scripts/build-dep-graph.py: Parse rules/*.mk dependency graph, compute critical path, fan-out/fan-in bottleneck analysis, and generate DOT/JSON output for visualization. - scripts/build-resource-monitor.sh: Sample CPU, memory, disk I/O, and Docker container count during builds for resource utilization analysis. Add "make build-report" target to slave.mk that runs the timing report and dependency analysis after a build completes. Example output from a VS build on 24-core/30GB machine: - 210 packages built in 53m wall time (173m CPU) - Max concurrency: 5 (with SONIC_CONFIG_BUILD_JOBS=4) - Critical path: 14 packages deep (libnl -> libswsscommon -> utilities) - Top bottleneck: LIBSWSSCOMMON with 48 downstream dependents Signed-off-by: Rustiqly <[email protected]> * Address Copilot review: fix 17 bugs in build analysis scripts - Use free -m with division instead of free -g to avoid rounding (#1) - Add = and ?= to Makefile dependency regex patterns (#2, #7) - CPU calculation now uses /proc/stat delta (two reads) (#3, sonic-net#14) - Fix misleading 'critical path estimate' comment (#4) - Fix parallelism timeline comment (60s not 10s) (#5) - Include after-relationship packages in fan stats (#6) - Guard disk I/O division by zero when INTERVAL<=1 (#8) - Remove unused elapsed_line variable (#9) - Remove redundant LIBSWSSCOMMON_DBG check (#10) - Remove active_make_jobs from CSV header comment (#11) - Wire up _RDEPENDS parsing to build reverse deps (#12) - Remove unnecessary 'if v' filter on rdeps JSON (#13) - Remove unused REPORT_FORMAT parameter (sonic-net#15) - Add cycle detection to critical path algorithm (sonic-net#16) - Add execute permission check for companion scripts (sonic-net#17) Signed-off-by: Rustiqly <[email protected]> --------- Signed-off-by: Rustiqly <[email protected]> Co-authored-by: Rustiqly <[email protected]>
Why I did it
The dash-ha container is always built and included in the image. However, when the dash-ha feature is not explicitly enabled/configured, the services create nuisance error messages when they attempt to start:
ERR container: docker get image version for dash-hadpu3 failed with 404 Client Error for http+docker://localhost/v1.50/containers/dash-hadpu3/json: Not Found ("No such container: dash-hadpu3")This change sets the dash-ha feature to be disabled by default. The service is masked so it won't attempt to run automatically. Users who want to use the dash-ha feature can enable it explicitly at runtime.
Work item tracking
How I did it
I explicitly set to service to track the same flag as the build.
How to verify it