State scripts#
State scripts enable EDA's unique ability to provide and act on the state of abstracted resources. They are being executed inside State Engine and are responsible for alarm generation, subscription and normalization of telemetry data, and publishing updates to the status field of resources, or the creation of state-only resources.
State scripts perform more work than just providing the state of a declarative abstracted intent. It adds operational capabilities to the EDA platform in a broad sense.
Triggering scripts#
A state script is attached to a particular resource via the applications manifest.yaml exactly the same way as configuration script:
apiVersion: core.eda.nokia.com/v1
kind: Manifest
metadata:
name: banners
spec:
components:
- crd:
path: banners/crds/banners.eda.local_bannerstates.yaml
schema: banners/openapiv3/eda_oas_banners.eda.local_bannerstates.json
- script:
path: banners/intents/bannerstate/state_intent.py
trigger:
kind: BannerState
type: state
The manifest presented above results in the logic contained in banners/intents/bannerstate/state_intent.py script being run whenever a BannerState resource is created or updated. The BannerState resource is added to the EDA API via the crd component defined in the same manifest file.
The state-related custom resource (BannerState in the example above) is typically created by the configuration script attached to the resource it represents.
Entrypoint#
Again, similar to configuration scripts, the entrypoint to a state script is the process_state_cr function, which is called by State Engine with the state resource object passed as a dictionary to the function.
The state script then can:
- query the EDA in-memory database (EDB) for more state information using
eda_state.list_dbmethod - update the EDB using
eda_state.update_dbmethod - generate alarms using
eda_state.update_alarmmethod when thresholds are crossed - normalize paths and present the state data in a vendor-agnostic way