[code sync] Merge code from sonic-net/sonic-buildimage:202405 to 202405#516
Merged
mssonicbld merged 2 commits intoAzure:202405from Jan 12, 2025
Merged
Conversation
Collaborator
mssonicbld
commented
Jan 12, 2025
mssonicbld
commented
mssonicbld
added a commit
to mssonicbld/sonic-buildimage-msft
that referenced
this pull request
Nov 12, 2025
…ions
#### Why I did it
Enable gnmi container to support gNOI operations that require host-level access:
1. **gNOI File Operations**: Implement File.TransferToRemote for downloading firmware directly to host `/tmp` and `/var/tmp` directories
2. **Host Command Execution**: Run SONiC commands like `show version`, `sonic-installer` via `chroot /mnt/host` for upgrade management
3. **Upgrade Handler**: Monitor host filesystem disk space and manage firmware operations
4. **Process Management**: Access host processes via shared PID namespace for operational monitoring
This transitions gnmi from a monitoring-only service to a full operational management interface supporting gNOI specification requirements.
##### Work item tracking
- Microsoft ADO: 33357627
#### How I did it
Modified gnmi container runtime configuration in `rules/docker-gnmi.mk`:
1. **Host Filesystem Access**:
- `-v /:/mnt/host:ro` - Read-only access to entire host filesystem
- `-v /tmp:/mnt/host/tmp:rw` - Writable access to host `/tmp` for firmware downloads
- `-v /var/tmp:/mnt/host/var/tmp:rw` - Writable access to host `/var/tmp` for persistent temp files
2. **Privileged Mode**:
- `--privileged` - Full device access and Linux capabilities
- `--pid=host` - Shared PID namespace for process visibility and management
This enables gnmi to:
- Download firmware files to host filesystem via gNOI File.TransferToRemote
- Execute host commands via `chroot /mnt/host show version`
- Monitor disk space before firmware operations
- Access host processes via `/proc/1/root/`
#### How to verify it
1. **Build and deploy**:
```bash
# Build SONiC image from feature/gnmi-privileged branch
make target/sonic-vs.img.gz
# Deploy and verify container configuration
docker inspect gnmi --format '{{.HostConfig.Privileged}}' # Should be: true
docker inspect gnmi --format '{{.HostConfig.PidMode}}' # Should be: host
docker inspect gnmi | grep -A5 Mounts # Should show /:/mnt/host:ro and writable tmp mounts
```
2. **Test host command execution**:
```bash
docker exec gnmi chroot /mnt/host show version
# Should display SONiC version from host
```
3. **Test gNOI File.TransferToRemote**:
```bash
# Download a file to host /tmp
gnmic -a device:8080 --insecure \
gnoi file transfer-to-remote \
--local-path /tmp/test.bin \
--remote-url http://server/firmware.bin \
--protocol HTTP
# Verify file on host
ls -l /tmp/test.bin
```
4. **Test disk space monitoring**:
```bash
gnmic -a device:8080 --insecure get \
--path "sonic/system/filesystem[path=/]/disk-space"
# Should return available space
```
5. **Verify write access**:
```bash
# Test writing to host /tmp
docker exec gnmi sh -c "echo test > /mnt/host/tmp/test.txt"
cat /tmp/test.txt # On host, should show: test
# Test read-only enforcement on other paths
docker exec gnmi sh -c "echo test > /mnt/host/etc/test.txt"
# Should fail with: Read-only file system
```
#### Which release branch to backport (provide reason below if selected)
- [ ] 202205
- [ ] 202211
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [x] 202505 - Required for gNOI-based upgrade workflow
#### Tested branch (Please provide the tested image version)
- [x] Built from feature/gnmi-privileged branch
- [x] Tested on vlab-01 (SONiC.20250505.03)
- [x] Verified all mount points and privileged mode settings
- [x] Tested host command execution and file operations
#### Description for the changelog
Add privileged mode and host filesystem access to gnmi container for gNOI operations support
#### Link to config_db schema for YANG module changes
N/A - Container runtime configuration only, no config_db or YANG changes
#### A picture of a cute animal (not mandatory but encouraged)
🐧 🔐
#### Related PRs
**sonic-net/sonic-gnmi**:
- Azure#521 - Implement gNOI File.TransferToRemote with security validation
- Azure#516 - Add upgrade handler with disk space monitoring
**sonic-net/sonic-mgmt**:
- #20916 - Add gnmi to privileged containers skip list in hardening tests
All PRs work together to enable gNOI-based upgrade operations:
- This PR: Provides container runtime privileges
- sonic-gnmi#521: Implements gNOI File operations with path security
- sonic-gnmi#516: Implements upgrade monitoring handler
- sonic-mgmt#20916: Updates test expectations for privileged gnmi container
Closed
11 tasks
mssonicbld
added a commit
to mssonicbld/sonic-buildimage-msft
that referenced
this pull request
Nov 20, 2025
…ions
#### Why I did it
Enable gnmi container to support gNOI operations that require host-level access:
1. **gNOI File Operations**: Implement File.TransferToRemote for downloading firmware directly to host `/tmp` and `/var/tmp` directories
2. **Host Command Execution**: Run SONiC commands like `show version`, `sonic-installer` via `chroot /mnt/host` for upgrade management
3. **Upgrade Handler**: Monitor host filesystem disk space and manage firmware operations
4. **Process Management**: Access host processes via shared PID namespace for operational monitoring
This transitions gnmi from a monitoring-only service to a full operational management interface supporting gNOI specification requirements.
##### Work item tracking
- Microsoft ADO: 33357627
#### How I did it
Modified gnmi container runtime configuration in `rules/docker-gnmi.mk`:
1. **Host Filesystem Access**:
- `-v /:/mnt/host:ro` - Read-only access to entire host filesystem
- `-v /tmp:/mnt/host/tmp:rw` - Writable access to host `/tmp` for firmware downloads
- `-v /var/tmp:/mnt/host/var/tmp:rw` - Writable access to host `/var/tmp` for persistent temp files
2. **Privileged Mode**:
- `--privileged` - Full device access and Linux capabilities
- `--pid=host` - Shared PID namespace for process visibility and management
This enables gnmi to:
- Download firmware files to host filesystem via gNOI File.TransferToRemote
- Execute host commands via `chroot /mnt/host show version`
- Monitor disk space before firmware operations
- Access host processes via `/proc/1/root/`
#### How to verify it
1. **Build and deploy**:
```bash
# Build SONiC image from feature/gnmi-privileged branch
make target/sonic-vs.img.gz
# Deploy and verify container configuration
docker inspect gnmi --format '{{.HostConfig.Privileged}}' # Should be: true
docker inspect gnmi --format '{{.HostConfig.PidMode}}' # Should be: host
docker inspect gnmi | grep -A5 Mounts # Should show /:/mnt/host:ro and writable tmp mounts
```
2. **Test host command execution**:
```bash
docker exec gnmi chroot /mnt/host show version
# Should display SONiC version from host
```
3. **Test gNOI File.TransferToRemote**:
```bash
# Download a file to host /tmp
gnmic -a device:8080 --insecure \
gnoi file transfer-to-remote \
--local-path /tmp/test.bin \
--remote-url http://server/firmware.bin \
--protocol HTTP
# Verify file on host
ls -l /tmp/test.bin
```
4. **Test disk space monitoring**:
```bash
gnmic -a device:8080 --insecure get \
--path "sonic/system/filesystem[path=/]/disk-space"
# Should return available space
```
5. **Verify write access**:
```bash
# Test writing to host /tmp
docker exec gnmi sh -c "echo test > /mnt/host/tmp/test.txt"
cat /tmp/test.txt # On host, should show: test
# Test read-only enforcement on other paths
docker exec gnmi sh -c "echo test > /mnt/host/etc/test.txt"
# Should fail with: Read-only file system
```
#### Which release branch to backport (provide reason below if selected)
- [ ] 202205
- [ ] 202211
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [x] 202505 - Required for gNOI-based upgrade workflow
#### Tested branch (Please provide the tested image version)
- [x] Built from feature/gnmi-privileged branch
- [x] Tested on vlab-01 (SONiC.20250505.03)
- [x] Verified all mount points and privileged mode settings
- [x] Tested host command execution and file operations
#### Description for the changelog
Add privileged mode and host filesystem access to gnmi container for gNOI operations support
#### Link to config_db schema for YANG module changes
N/A - Container runtime configuration only, no config_db or YANG changes
#### A picture of a cute animal (not mandatory but encouraged)
🐧 🔐
#### Related PRs
**sonic-net/sonic-gnmi**:
- Azure#521 - Implement gNOI File.TransferToRemote with security validation
- Azure#516 - Add upgrade handler with disk space monitoring
**sonic-net/sonic-mgmt**:
- #20916 - Add gnmi to privileged containers skip list in hardening tests
All PRs work together to enable gNOI-based upgrade operations:
- This PR: Provides container runtime privileges
- sonic-gnmi#521: Implements gNOI File operations with path security
- sonic-gnmi#516: Implements upgrade monitoring handler
- sonic-mgmt#20916: Updates test expectations for privileged gnmi container
Merged
11 tasks
mssonicbld
added a commit
to mssonicbld/sonic-buildimage-msft
that referenced
this pull request
Dec 6, 2025
…tomatically (#24733) #### Why I did it src/sonic-linux-kernel ``` * 8d5dee7 - (HEAD -> 202505, origin/202505) Automated agent pool migration (Azure#516) (34 hours ago) [yijingyan2] ``` #### How I did it #### How to verify it #### Description for the changelog
bingwang-ms
pushed a commit
that referenced
this pull request
Jan 16, 2026
…lly (#24171) #### Why I did it src/sonic-gnmi ``` * 714fb1a - (HEAD -> master, origin/master, origin/HEAD) Add operational handler with disk space query (#516) (2 days ago) [Dawei Huang] ``` #### How I did it #### How to verify it #### Description for the changelog
mssonicbld
added a commit
that referenced
this pull request
Jan 27, 2026
…iner for gNOI operations (#1831) #### Why I did it Enable gnmi container to support gNOI operations that require host-level access: 1. **gNOI File Operations**: Implement File.TransferToRemote for downloading firmware directly to host `/tmp` and `/var/tmp` directories 2. **Host Command Execution**: Run SONiC commands like `show version`, `sonic-installer` via `chroot /mnt/host` for upgrade management 3. **Upgrade Handler**: Monitor host filesystem disk space and manage firmware operations 4. **Process Management**: Access host processes via shared PID namespace for operational monitoring This transitions gnmi from a monitoring-only service to a full operational management interface supporting gNOI specification requirements. ##### Work item tracking - Microsoft ADO: 33357627 #### How I did it Modified gnmi container runtime configuration in `rules/docker-gnmi.mk`: 1. **Host Filesystem Access**: - `-v /:/mnt/host:ro` - Read-only access to entire host filesystem - `-v /tmp:/mnt/host/tmp:rw` - Writable access to host `/tmp` for firmware downloads - `-v /var/tmp:/mnt/host/var/tmp:rw` - Writable access to host `/var/tmp` for persistent temp files 2. **Privileged Mode**: - `--privileged` - Full device access and Linux capabilities - `--pid=host` - Shared PID namespace for process visibility and management This enables gnmi to: - Download firmware files to host filesystem via gNOI File.TransferToRemote - Execute host commands via `chroot /mnt/host show version` - Monitor disk space before firmware operations - Access host processes via `/proc/1/root/` #### How to verify it 1. **Build and deploy**: ```bash # Build SONiC image from feature/gnmi-privileged branch make target/sonic-vs.img.gz # Deploy and verify container configuration docker inspect gnmi --format '{{.HostConfig.Privileged}}' # Should be: true docker inspect gnmi --format '{{.HostConfig.PidMode}}' # Should be: host docker inspect gnmi | grep -A5 Mounts # Should show /:/mnt/host:ro and writable tmp mounts ``` 2. **Test host command execution**: ```bash docker exec gnmi chroot /mnt/host show version # Should display SONiC version from host ``` 3. **Test gNOI File.TransferToRemote**: ```bash # Download a file to host /tmp gnmic -a device:8080 --insecure \ gnoi file transfer-to-remote \ --local-path /tmp/test.bin \ --remote-url http://server/firmware.bin \ --protocol HTTP # Verify file on host ls -l /tmp/test.bin ``` 4. **Test disk space monitoring**: ```bash gnmic -a device:8080 --insecure get \ --path "sonic/system/filesystem[path=/]/disk-space" # Should return available space ``` 5. **Verify write access**: ```bash # Test writing to host /tmp docker exec gnmi sh -c "echo test > /mnt/host/tmp/test.txt" cat /tmp/test.txt # On host, should show: test # Test read-only enforcement on other paths docker exec gnmi sh -c "echo test > /mnt/host/etc/test.txt" # Should fail with: Read-only file system ``` #### Which release branch to backport (provide reason below if selected) - [ ] 202205 - [ ] 202211 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [x] 202505 - Required for gNOI-based upgrade workflow #### Tested branch (Please provide the tested image version) - [x] Built from feature/gnmi-privileged branch - [x] Tested on vlab-01 (SONiC.20250505.03) - [x] Verified all mount points and privileged mode settings - [x] Tested host command execution and file operations #### Description for the changelog Add privileged mode and host filesystem access to gnmi container for gNOI operations support #### Link to config_db schema for YANG module changes N/A - Container runtime configuration only, no config_db or YANG changes #### A picture of a cute animal (not mandatory but encouraged) 🐧 🔐 #### Related PRs **sonic-net/sonic-gnmi**: - #521 - Implement gNOI File.TransferToRemote with security validation - #516 - Add upgrade handler with disk space monitoring **sonic-net/sonic-mgmt**: - #20916 - Add gnmi to privileged containers skip list in hardening tests All PRs work together to enable gNOI-based upgrade operations: - This PR: Provides container runtime privileges - sonic-gnmi#521: Implements gNOI File operations with path security - sonic-gnmi#516: Implements upgrade monitoring handler - sonic-mgmt#20916: Updates test expectations for privileged gnmi container
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.