Skip to content

Enhance device capabilities and constraints management - #381

Open
spulkit138 wants to merge 44 commits into
developmentfrom
feature/device-constraints
Open

Enhance device capabilities and constraints management#381
spulkit138 wants to merge 44 commits into
developmentfrom
feature/device-constraints

Conversation

@spulkit138

@spulkit138 spulkit138 commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Enhance device capabilities and constraints management

Summary

  • This PR introduces a consolidated system for managing device capabilities and runtime constraints. Implementation of (Device Runtime SUP)[https://github.com/margo/specification-enhancements/blob/main/proposals/sup_device_specific_runtime_affinity_matching.md]
  • Adds core logic to define, validate, store, and enforce capability definitions and constraint rules across devices.
  • Includes implementation, tests, and documentation updates to support the new capabilities/constraints workflow.

Key changes

  • New modules and/or services for:

    • Device capability model: canonical representation of device capabilities and metadata.
    • Constraints manager/engine: declarative constraint definitions, evaluation, and enforcement.
    • Validation and registration hooks: capability/constraint validation at device onboarding and updates.
  • Persistence and migrations:

    • Adds persistency support for capability definitions and constraints (DB schema and/or storage updates included).
  • Tests:

    • Unit tests and integration tests covering capability validation, constraint evaluation, edge cases and error handling.
  • Docs:

    • Developer docs and usage examples for defining capabilities and constraints, and running migration/scripts.

Checklist

  • Implementation of device capability model
  • Constraints manager/engine implemented
  • Unit + integration tests added
  • Docs / usage examples added

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…s and custom runtime

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…ibrary

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…pp pkg id

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…eligible devices

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…g app

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…nerated

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…requirements

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…ased on label matching

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…t library

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…e deploying app

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
…ment

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
@spulkit138
spulkit138 force-pushed the feature/device-constraints branch from 0bf620d to 069e442 Compare August 24, 2026 05:28
Comment thread docs/repo-structure.md
- **Workload management** (`workloads/`) - Helm and Docker Compose clients
- **Archive** (`archive/`) - Unpacking or packing archives(tar.gz) etc..
- **Pointer operations** (`pointers/`) - Some helper functions to deep clone, safely get pointer to temp variables etc...
- **Device Constraint Selector Engine** (`constraints/`) - Reusable device eligibility checking library for the checks defined in [Device Runtime Affinity SUP](https://github.com/margo/specification-enhancements/blob/main/proposals/sup_device_specific_runtime_affinity_matching.md)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to change this path once it is merged to completed folder or better to provide specification PR path as there might be some changes post specification-enhancement PR approval.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked in specification PR , this exact content is not there, hence I would say we can change path once it is moved to completed folder.

Comment thread docs/repo-structure.md

**Tools:**
- **Setup script** (`wfm.sh`, `device-agent.sh`) - Automated environment setup (Harbor, device's Workload Fleet Management Client, Symphony etc.)
- **Label Generator Script** (`create-device-labels.sh`) - This script helps users generate labels for a device as per the guidelines defined here: [Device Runtime Affinity SUP](https://github.com/margo/specification-enhancements/blob/main/proposals/sup_device_specific_runtime_affinity_matching.md)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here are refer the specification PR because specification-enhancement moved to completed folder from proposal folder once spec PR is approved/merged to pre-draft

@spulkit138 spulkit138 Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked in margo/specification#203 , this exact content is not there, hence I would say we can change path once it is moved to completed folder, as this PR will be merged in main when specification PR will be merged.

in: query
schema: { type: string }
description: Token for pagination
- name: appPackageId

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the purpose of this additional parameter, where this input come from?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, WFM CLI would show "eligible or not eligible" while selecting device for a particular deployment. For that eligibility check, List Device needs an optional parameter "application package Id" in order to get application device constraints for that particular application package. More information is present in description of this PR : #374

oneOf:
- $ref: '#/components/schemas/HelmApplicationDeploymentProfileComponent'
- $ref: '#/components/schemas/ComposeApplicationDeploymentProfileComponent'
- $ref: '#/components/schemas/CustomApplicationDeploymentProfileComponent'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have discussed this already, as you have one more profile component (custom). shall we merge all as single for better clarity? what is your thought?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pointed out this previously that does non-standard API need to change as well in compose oci changes. My point was, for parts which are same in standard & non-standard, we should keep standard as single source of truth. Hence change here should be done and should be same to what is present in standard. Custom Runtime PR introduces a custom runtime apart from helm/compose. Hence this change was added.

If we align to change it, my suggestion would be to either change it as a separate PR and then we pull changes in this to align it; OR after merging this a separate PR should be raised for that change. That ways, we can keep these two things separate.

Comment on lines +4 to +11
"labels": {
"northstarida.com/hypervisor": "hyper-v",
"northstarida.com/wasm.runtime": [
"wamr"
],
"northstarida.com/wasm.package.format": [
".wasm",
".aot"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have single static capability file for both helm and compose and we update supportedDeploymentTypes (any other attributes) during setup

Introducing these labels are not necessary from helm and compose right?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Labels are totally optional. Here, they are just placeholders for reference. They are not used while deployment. In installation scripts, I have provided a different way to add labels while installing WFM Client. And if labels are not provided at installation time, these placeholder labels are removed automatically.

Keeping it here just because if someone wants to deploy as a binary, they will know how labels can be added, and they can modify/remove as required.

Comment thread poc/device/agent/deployment.go Outdated
// Only deploy if not already installed
if currentState != sbi.DeploymentStatusManifestStatusStateInstalled {
dm.log.Debugw("deploying pending deployment", "deploymentId", deploymentId)
// TODO: Check if device is eligible or not, if not, set it to failed state even before deployment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is checking device eligibility planned later? IMO, WFM will filter device is eligible or not.?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to remove this TODO comment. I have removed it now.

As per discussion, WFM will just show whether a device is eligible or not. Selection of a particular device still remains with the user. However, on Device agent side, if a particular application is ineligible, it is put in FAILED mode without even deploying it.

Signed-off-by: Pulkit Sharma <pulkit.d.sharma@capgemini.com>
@vireshnavalli vireshnavalli added SPRINT_23 SPRINT_23 and removed SPRINT_22 SPRINT_22 labels Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request SPRINT_23 SPRINT_23

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[TASK: ] Integrate Device Selector in WFM & WFM Client

2 participants