Skip to content

Improve deployment status / desired state mechanics and workflows #156

Description

@ajcraig

Feature description

  • Improve workload fleet management API mechanics regarding when the device is deploying/updating an application along with status reporting.

Provide adequate technical acceptance criteria(s) associated with this feature below:

Details about deployment status semantics - Define when devices report (state transitions, periodic heartbeat, or both), how retries work (backoff, max age), how idempotency/dedup works, and what servers should expect during long disconnects.​

Details about desired state semantics - Clarify what constitutes a "new revision" vs "same deployment updated" (does ID change on parameter change?), what failure handling is required (stop + report vs rollback), and whether devices must retry component apply.​

Although not required, it is highly encouraged to provide feature use-cases below:

Improved workload management through the Management interface definition.

Additional information

Medium to High impact on GA release - if we do not specify when the WFM client reports workload state, or how a WFM client acts upon failed deployments (will it retry forever, give up after N attempts, backoff timers used, ...?), a WFM and WFM user would not know if and how to react upon failures - and might not be able to observe the actual state of deployments.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions