Versions Compared

Old Version 6

changes.mady.by.user Mathis Moder

Saved on

compared with

New Version 7

changes.mady.by.user Mathis Moder

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Status: In Progress

Overview

<Briefly describe the problem being solved, not how the problem is solved, just focus on the problem. Think about why the feature is needed, and what is the relevant context to understand the problem.>

In edge-nodes (e.g. moving cars or other critical equipment), a new Safety Critical "Change Freeze" mode

...

should be introduced. The Agent will continue to run any active agreements / workloads but will not

...

 download/start new services/cancel existing services

Goal: prevent

...

workloads from changing while the edge node is in a "safety critical state".

Design

...

Option A)

...

prevent any workload changes of the agent

...

via API / cli

An external invocation would set the state actively from outside of the agent to "freeze" . the Any agreements would be negotiated as usual, but the download of the service would not be executed unless the state is not freezed. 

Command syntax would be:

no more frozen. In order to avoid any situation where the agent would be frozen forever, the API could also accept an timeout parameter, after which the agent would resume as normal.


hzn node freeze --help usage: hzn node freeze <command> [<args> ...] Commands: freeze enable <--duration=nn> disable
Expand
titleInitial comments from John
Code Block

Possibly send heartbeats but not accept node property updates or changes

Possibly allow geofencing information updates?  Where the edge node is located might be important to know.  Aha "The car is on the driveway, geofenced at home" is an important clue that might allow the agent to trigger changes to workloads.   If the car is at the supermarket, not a good idea.

Governance should restart the agreement, if it dies unexpectedly - tricky?

node health state ? 

HA node groups need to skip over nodes that are in ChangeFreeze state.  This is orthogonal to the reason for a HA group.  Unsupported configuration.


Let the external change "The car is in park and the GPS knows that the car is "home" - Call the API to change out of ChangeFreeze state".

The agent never decides for itself that it out of ChangeFreeze state

Build a "Agent Config State" API

If a secret changes, the agbot sends a message of a change, if the agent doesn't see or handle that message, what happens?  Max?  Would the agreement get cancelled if the agent doesn't reply?

MMS handling of agents in ChangeFreeze status  -

ESS should also go into ChangeFreeze state as well.  It should not look for model updates while the edge node is in changefreeze state.

Node Management- behavior?

Option B) per service: include an "change-constraint" in the deployment policy

this This approach could be compared to a normal node- property/constraint negotiation, but would only be relevant for the actual (de)activation of the payload. In this case _change.allow would be a reserved constraint parameter-parameter map to avoid changes to the definitions on the first level. If this constraint resolves to true the service can be installed/removed, if it is false the service will neither be installed nor uninstalled.


Code Block
{
  "constraints": [
    "openhorizon.arch == arm64",
    "_change.allow": [
       "property.example": >= 1
    ]
  ]
}

...