yangyl/managed-portal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8c7c713fee9d56964ba90aba44e1110e678e0f6c
managed-portal/tasks/todo.md

5.2 KiB
Raw Blame History

Task Plan

Checklist

  • Inspect the published managed-portal installer and release manifest under root@10.8.0.1:/var/www/html/ai_deploy.
  • Confirm the registry tags currently published for managed-portal, managed-portal-web, people-flow-project, and store-dwell-alert.
  • Prepare 10.8.0.14 for an installer-aligned rollout of the four-service managed-portal stack.
  • Recreate the four target containers on 10.8.0.14 using the published release version and corresponding Compose layout.
  • Verify the running stack on 10.8.0.14 uses the published registry images and the installer-managed Compose project.

Scope And Risks

  • Scope: use the published managed-portal release artifacts on 10.8.0.1 as the source of truth for image names, tags, and Compose topology.
  • Scope: update the four-service managed-portal group on 10.8.0.14: managed-portal, managed-portal-web, people-flow-project, and store-dwell-alert.
  • Scope: keep unrelated stacks, especially the iot-main video-recognition project, untouched.
  • Risk: the current four containers on 10.8.0.14 are not managed by one Compose project, so installer-based recreation will conflict on fixed container names unless the old containers are replaced cleanly.
  • Risk: the published installer seeds config, data, outputs, and weights under /opt/managed-portal-releases; switching to it changes the runtime paths from the current ad hoc directories.
  • Risk: service recreation causes a brief interruption for the portal and both child-service APIs.

Validation Intent

  • Read the published installer and release-manifest.env to confirm the exact release version and image references.
  • Verify the registry exposes the four target tags before rollout.
  • Use the installer-aligned Compose files and environment from the published bundle, not a hand-built local variant.
  • Confirm the final containers are recreated from the published registry images and are running under the installer-managed release directory.

Review

  • Status: complete.
  • Result:
    • Confirmed the published managed-portal installer source of truth is root@10.8.0.1:/var/www/html/ai_deploy/install-managed-portal-20260519-f3f40b5-11.sh.
    • Confirmed the published registry images in release-manifest.env are:
      • ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11
      • ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11
      • ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11
      • ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11
    • Confirmed all four image tags exist in the registry on 10.8.0.14.
    • Extracted the published release bundle to /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11.
    • Generated /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env from the published release, while keeping the host-specific data and output directories on 10.8.0.14.
    • Replaced the ad hoc managed-portal, managed-portal-web, people-flow-project, and store-dwell-alert containers with the installer-managed Compose project under /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml.
    • Migrated store-dwell-alert to a schema-compatible config under /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/managed/store_dwell_alert/config/local.yaml while preserving the current 192.168.0.5 RTSP source.
    • Kept the current people-flow config/output/weights directories, but removed gpus: all from the release Compose file because the host currently fails nvidia-container-cli startup with an NVML driver/library mismatch. The new image falls back to CPU at runtime and still reports healthy.
  • Verification:
    • Published release manifest from 10.8.0.1 resolves to the four 20260519-f3f40b5-11 image tags above.
    • Registry presence checks from 10.8.0.14 succeeded for all four image tags via docker manifest inspect.
    • sudo docker compose --env-file /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env -f /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml ps showed:
      • managed-portal -> ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11, Up
      • managed-portal-web -> ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11, Up
      • people-flow-project -> ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11, Up (healthy)
      • store-dwell-alert -> ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11, Up (healthy)
    • sudo docker inspect confirmed the four containers use the published registry image references; people-flow-project and store-dwell-alert report healthy.
    • curl -fsS http://127.0.0.1:13000 succeeded.
    • curl -fsS http://127.0.0.1:13000/api/managed-services returned both managed services with status: "running".
    • curl -fsS http://127.0.0.1:13000/api/managed-services/store_dwell_alert returned the 192.168.0.5 RTSP source and status: "running".
    • curl -fsS http://127.0.0.1:13000/api/managed-services/people_flow_project returned the 192.168.0.4 RTSP source and status: "running".