ITEP-83024 [Design] SceneScape Core Deployment Package

[Irakus]

📝 Description

Adding design doc about extracting SceneScape Core deployment packages for easier installation for general use cases.

✨ Type of Change

Select the type of change your PR introduces:

• 🐞 Bug fix – Non-breaking change which fixes an issue
• 🚀 New feature – Non-breaking change which adds functionality
• 🔨 Refactor – Non-breaking change which refactors the code base
• 💥 Breaking change – Changes that break existing functionality
• 📚 Documentation update
• 🔒 Security update
• 🧪 Tests
• 🚂 CI

🧪 Testing Scenarios

Describe how the changes were tested and how reviewers can test them too:

• ✅ Tested manually
• 🤖 Ran automated end-to-end tests

✅ Checklist

Before submitting the PR, ensure the following:

• 🔍 PR title is clear and descriptive
• 📝 For internal contributors: If applicable, include the JIRA ticket number (e.g., ITEP-123456) in the PR title. Do not include full URLs
• 💬 I have commented my code, especially in hard-to-understand areas
• 📄 I have made corresponding changes to the documentation
• ✅ I have added tests that prove my fix is effective or my feature works

[tdorauintc]

There is a significant difference between Docker and Kuberenetes deployments:

• for Docker the core SceneScape services and Camera Pipelines (including models) are configured separately and can be deployed independently.
• for Kubernetes it is one of core SceneScape services (manager) that manages the configuration (UI) of Camera Pipelines and deploys them (kubeclient).

This means we will need to plan the implementation of core deployment package, so that it does impact UX negatively for Kubernetes.

For example one consequence of extracting core deployment is that models will no longer be managed via manager UI in Kubernetes (which I like as a general direction - there are other services like model_downloader that we can reuse for this purpose and integrate them with Geti).
Ideally, we add such an external model managing service integration when introducing core deployment package. Alternatively, we let users manage models on their own using pure Kubernetes volume w/o any UI, we just provide some CLI tools to install them into the volume.

[Irakus]

For the first part: compose and helm deployments will still be separate things, so there's no problem in adding kubeclient to the latter.
For second part, I'd need a better understanding of how models are managed to comment.

[Irakus]

@copilot /review

[dmytroye]

Could you please add more details about what does current state mean.

[dmytroye]

Maybe let's add something like: "without manually deleting sample scenes/camera configurations from demo setup".

[dmytroye]

Can we group elements that do not require example data to be configured for demo purpose?

[dmytroye]

And create new sample applications (as Smart intersection)?

[dmytroye]

Can we adjust make targets to use core deployment + automate adding of existing Demo sample data?

[Irakus]

To keep compatibility, we can "hide" new implementation behind old make targets.

[Copilot]

@copilot /review

Here's my review of the design document:

Structure & Template Compliance: ✅ Follows the design doc template correctly with all required sections.

Minor observations:

1. Line 39: "Currently all SceneScape-based apps looks similar" → should be "look similar" (subject-verb agreement).
2. Line 17: "Split all demos related components" → "demo-related components" reads more naturally.
3. The point @tdorauintc raised about Docker vs Kubernetes differences (kubeclient in manager for K8s, separate camera pipeline deployment for Docker) could be worth capturing in the design doc — perhaps as an additional consideration in Section 5 or as an Open Question in Section 10. This would document the known architectural divergence for future implementers.
4. Section 6 (Alternatives Considered) is minimal — only states the status quo. Could benefit from briefly mentioning other approaches that were evaluated and dismissed.

REUSE compliance: ✅ Markdown files are covered by REUSE.toml annotations, no inline header needed.

Overall the document is well-structured and clearly communicates the motivation and phased approach.