Core collection#
The Core collection provides modules for the EDA's core API, such as user management, transaction handling, alarm monitoring, query execution, and more.
Transactions#
Carrying out atomic transactions across the whole infrastructure is one of the key features Nokia EDA offers.
While individual Ansible collections contain modules to perform one-shot operations on resources, the Transaction API allows for more complex workflows that involve combining multiple resource operations into a single atomic transaction, running dry runs, inspecting diffs and rolling back changes if needed.
The nokia.eda_core_v1.transaction.v2.transaction module runs the transactions and has the following structure:
- name: Run a transaction
nokia.eda_core_v1.transaction.v2.transaction:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}" #(4)!
description: "interface deletion"
dryRun: false #(1)!
detailLevel: "detailed" #(2)!
crs:
- type:
create:
value: # resource definition
- type:
modify:
value: # resource definition
- type:
replace:
value: # resource definition
- type:
patch:
patchOps: # patch operations
target:
gvk:
group:
version:
kind:
name:
namespace:
- type:
delete:
gvk:
group:
version:
kind:
name:
namespace:
dryRun: If set to true, the dry run will be performed by EDA and no changes will be made to the actual resource/nodes.detailLevel: Defines the detail level of the transaction results. One of:standard,detailed. Detailed level includes the diffs of the changed resources and node configurations.
- Remember to set the
tls_skip_verifyparameter tofalseif your EDA instance uses self-signed certificates.
In its crs field, a user provides a list of resources to include in the transaction and associated, easy to understand operation:
- create - creates a resource. Fails if it already exists.
- modify - modifies an existing resource. Fails if it does not exist.
- replace - replaces the existing resource, creates if it does not exist.
- patch (JSON patch RFC 6902)
- delete - deletes a resource. Fails if it does not exist.
Using these operations a user can arbitrary number of resources and operations with them to a single transaction and run them together in an atomic, all-or-nothing, fashion.
Create#
Let's explore how to use transaction module for creating resources. We will create two Banner resources in a single transaction. First Banner will target leaf nodes and second Banner will target spine nodes.
The transaction module expects us to provide the resources definitions in the crs field:
- name: Create two banners
nokia.eda_core_v1.transaction.v2.transaction:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
description: "interface deletion"
dryRun: false
detailLevel: "detailed"
crs:
- type:
create:
value: # first Banner resource
- type:
create:
value: # second Banner resource
You should use the resource module from the application collection to register the value of a resource in a variable. Using the Siteinfo collection and its banner resource we can create the two Banner resources:
Note, both of our resources don't have
state: present/query/absentdefined, which means the resource will be just created in memory.
Let's break down the tx-create-banners.yaml playbook into its individual tasks. We start first with registering two banner resources in their distinct variables, without specifying the state attribute:
Step 1: register resources to create
- name: Create Two Banners
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
register: token
- name: Create banner for leafs
nokia.eda_siteinfo_v1alpha1.banner:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
resource:
metadata:
labels:
some-label: ansible-demo
namespace: eda
name: demo-leaf-banner
spec:
loginBanner: "This is a demo banner provisioned by Ansible on leafs"
nodeSelector:
- eda.nokia.com/role=leaf
# the `state` attribute should not be present
# to register the resource value as it is defined in a variable banner_leafs
# state: present
register: banner_leafs
- name: Create banner for spines
nokia.eda_siteinfo_v1alpha1.banner:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
resource:
metadata:
labels:
some-label: ansible-demo
namespace: eda
name: demo-spine-banner
spec:
loginBanner: "This is a demo banner provisioned by Ansible on leafs"
Next we use the transaction module and add the registered objects with the corresponding create type:
Step 2: Run transaction
- eda.nokia.com/role=spine
register: banner_spines
- name: Run transaction
nokia.eda_core_v1.transaction.v2.transaction:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
description: "Banners creation"
dryRun: false
detailLevel: "detailed"
crs:
- type:
create:
value: "{{ banner_leafs.result }}"
- type:
create:
value: "{{ banner_spines.result }}"
register: tx
When the transaction API is used, the EDA API server immediately responds to the transaction run request with the transaction ID and starts to work on the transaction in the background, allowing for asynchronous processing of the requested changes.
Now we want to check the transaction status and do that only when the transaction is complete. To achieve this we will use the nokia.eda_core_v1.transaction.v2.result.execution module, that returns execution results of the transaction and can be instructed to wait for the transaction to complete.
Step 3: Waiting for tx to complete and getting results
ansible.builtin.debug:
var: tx
- name: Get TX execution result
nokia.eda_core_v1.transaction.v2.result.execution:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx.result.id }}"
waitForComplete: true
failOnErrors: true
register: result_execution
result_execution:
changed: false
failed: false
result:
changedCrs:
- gvk:
group: core.eda.nokia.com
kind: NodeConfig
version: v1
names:
- banner-demo-leaf-banner-leaf1
- banner-demo-leaf-banner-leaf2
- banner-demo-spine-banner-spine1
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: Banner
version: v1alpha1
names:
- demo-leaf-banner
- demo-spine-banner
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: BannerState
version: v1alpha1
names:
- demo-leaf-banner
- demo-spine-banner
namespace: eda
executionSummary: "intents-run: 2, nodes-changed: 3, engine-time=17.99901ms,
push-to-node=203.717847ms, publish-cr=11.082806ms, git-save=577.012717ms"
generalErrors: {}
intentsRun:
- errors: []
intentName:
gvk:
group: siteinfo.eda.nokia.com
kind: Banner
version: v1alpha1
name: demo-leaf-banner
namespace: eda
outputCrs:
- gvk:
group: core.eda.nokia.com
kind: NodeConfig
version: v1
name: banner-demo-leaf-banner-leaf1
namespace: eda
- gvk:
group: core.eda.nokia.com
kind: NodeConfig
version: v1
name: banner-demo-leaf-banner-leaf2
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: BannerState
version: v1alpha1
name: demo-leaf-banner
namespace: eda
script:
executionTime: 17581
- errors: []
intentName:
gvk:
group: siteinfo.eda.nokia.com
kind: Banner
version: v1alpha1
name: demo-spine-banner
namespace: eda
outputCrs:
- gvk:
group: core.eda.nokia.com
kind: NodeConfig
version: v1
name: banner-demo-spine-banner-spine1
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: BannerState
version: v1alpha1
name: demo-spine-banner
namespace: eda
script:
executionTime: 17177
nodesWithConfigChanges:
- errors: {}
name: leaf1
namespace: eda
- errors: {}
name: leaf2
namespace: eda
- errors: {}
name: spine1
namespace: eda
topologySupported: true
status: 200
The transaction execution results will provide you with lots of information about the transaction such as the intent scripts that were run, the changed and output resources and the nodes that were affected by the transaction.
You can also get the transaction summary results by using the following module:
Step 4: Optionally check for tx summary
- name: print response
ansible.builtin.debug:
var: result_execution
- name: Get TX summary
nokia.eda_core_v1.transaction.v2.result.summary:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx.result.id }}"
The transaction summary provides you with the details pertaining to the transaction and its status. Including the commit hash it was recorded with, completion status, etc.
Dry run#
Being able to transact many resources in an atomic and idempotent way is great, but being able to dry run the transaction gives the users confidence in the changes being made and adds this sweet reliability to Nokia EDA automation platform.
To demonstrate how dry runs work we will stage a change of removing the demo-leaf-banner resource created in the previous step, but instead of executing the transaction as usual, we will switch the dryRun flag to true.
When deleting resources via transaction, all you need to provide is the resource identification:
- the
group(API group) the resource belongs to. - the
versionof the API this resource is using. - the
kind- the resource kind as seen in the UI - the
nameof the resource to delete - the
namespacethe resource is in
The first three values can be easily obtained from the UI or using the app metadata modules.
Here is how the whole playbook would look like:
- name: Dry run Banner deletion
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Run transaction
nokia.eda_core_v1.transaction.v2.transaction:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
description: "Banners creation"
dryRun: true
detailLevel: "detailed"
crs:
- type:
delete:
gvk:
group: siteinfo.eda.nokia.com
version: v1alpha1
kind: Banner
name: demo-leaf-banner
namespace: eda
register: tx
- name: print response
ansible.builtin.debug:
var: tx
- name: Get TX execution result
nokia.eda_core_v1.transaction.v2.result.execution:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx.result.id }}"
waitForComplete: true
failOnErrors: true
register: result_execution
- name: print response
ansible.builtin.debug:
var: result_execution
- name: Get TX summary
nokia.eda_core_v1.transaction.v2.result.summary:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx.result.id }}"
register: result_summary
- name: print response
ansible.builtin.debug:
var: result_summary
result_execution:
changed: false
failed: false
result:
changedCrs:
- gvk:
group: core.eda.nokia.com
kind: NodeConfig
version: v1
names:
- banner-demo-leaf-banner-leaf1
- banner-demo-leaf-banner-leaf2
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: Banner
version: v1alpha1
names:
- demo-leaf-banner
namespace: eda
- gvk:
group: siteinfo.eda.nokia.com
kind: BannerState
version: v1alpha1
names:
- demo-leaf-banner
namespace: eda
executionSummary: "intents-run: 1, nodes-changed: 2, engine-time=763.395µs,
push-to-node=12.228518ms"
generalErrors: {}
intentsRun:
- errors: []
intentName:
gvk:
group: siteinfo.eda.nokia.com
kind: Banner
version: v1alpha1
name: demo-leaf-banner
namespace: eda
outputCrs: []
script:
executionTime: 14
nodesWithConfigChanges:
- errors: {}
name: leaf1
namespace: eda
- errors: {}
name: leaf2
namespace: eda
topologySupported: true
status: 200
By running a transaction in dry run mode you get the visibility into the following questions every operator seeks answers to:
- Are your changes valid?
- Will the transaction succeed if you run it?
- What nodes will be affected by the change?
- What diffs will be produced by the change from the nodes perspective?
The first two questions are answered by the fact that the transaction returns no errors and the result summary output says success: true. This gives operators confidence that their changes are valid and have great chance of succeeding when pushed to the nodes.
In the execution results the output contains .result.nodesWithConfigChanges list that shows which nodes would be affected by the change. As we removed the banner resource that was targeting the leaf nodes we can see that only the leaf nodes are included in this list:
nodesWithConfigChanges:
- errors: {}
name: leaf1
namespace: eda
- errors: {}
name: leaf2
namespace: eda
Diffs#
When transaction is executed with the detailLevel: "detailed" argument, EDA generates the diff for the changed resources and the node configurations participating in this transaction.
The diffs are stored in the "before and after" fashion and are kept in memory. For example, in the dry run that we ran above the transaction number that was recorded was 63. We can display the node configuration using the nokia.eda_core_v1.transaction.v2.result.diffs.nodecfg module:
We run this playbook with overriding the static tx id like this:
- name: Get Node Diff
hosts: all
gather_facts: false
vars:
tx_id: 60
node: leaf1
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get node diff
nokia.eda_core_v1.transaction.v2.result.diffs.nodecfg:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx_id }}"
namespace: "eda"
node: "{{ node }}"
register: response
- name: print var
ansible.builtin.debug:
var: response
Note, that the result is structured as:
Where each data block contains the config in the format that is used by EDA to push changes to the devices (native CLI or Openconfig).
response:
changed: false
failed: false
result:
after:
data: |-
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/4 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/5 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/6 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/7 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/8 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/9 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/10 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag1
lacp-port-priority 32768
}
}
interface ethernet-1/11 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag1
lacp-port-priority 32768
}
}
interface ethernet-1/12 {
description lag-leaf1-2-e1212-local
admin-state enable
ethernet {
aggregate-id lag2
lacp-port-priority 32768
}
}
interface lag1 {
description lag-leaf1-e1011-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 2
system-id-mac FE:2F:AA:00:00:02
system-priority 32768
}
}
}
interface lag2 {
description lag-leaf1-2-e1212-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 3
system-id-mac FE:2F:AA:00:00:03
system-priority 32768
}
}
}
interface mgmt0 {
admin-state enable
subinterface 0 {
admin-state enable
ipv4 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
ipv6 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
}
}
network-instance mgmt {
type ip-vrf
admin-state enable
description "Management network instance"
interface mgmt0.0 {
}
protocols {
linux {
import-routes true
export-routes true
}
}
}
system {
aaa {
authentication {
authentication-method [
local
]
admin-user {
password $aes1$ATetY3KV3PlLMW8=$tdr4AZSOUoHYR+Oatw6w4g==
}
}
authorization {
role sudo {
superuser true
services [
cli
gnmi
gnoi
gnsi
netconf
]
}
}
server-group local {
type local
}
}
ssh-server mgmt {
admin-state enable
network-instance mgmt
}
boot {
autoboot {
admin-state disable
}
}
configuration {
role sudo {
}
}
grpc-server mgmt {
admin-state enable
rate-limit 65535
session-limit 1024
metadata-authentication true
tls-profile EDA
network-instance mgmt
port 57400
services [
gnmi
gnoi
gnsi
]
gnmi {
commit-save false
}
}
lldp {
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
}
interface ethernet-1/4 {
admin-state enable
}
interface ethernet-1/5 {
admin-state enable
}
interface ethernet-1/6 {
admin-state enable
}
interface ethernet-1/7 {
admin-state enable
}
interface ethernet-1/8 {
admin-state enable
}
interface ethernet-1/9 {
admin-state enable
}
interface ethernet-1/10 {
admin-state enable
}
interface ethernet-1/11 {
admin-state enable
}
interface ethernet-1/12 {
admin-state enable
}
}
name {
host-name leaf1
}
network-instance {
protocols {
evpn {
ethernet-segments {
bgp-instance 1 {
ethernet-segment lag-leaf1-2-e1212-local {
admin-state enable
esi 00:FE:2F:AA:00:00:03:00:00:00
multi-homing-mode all-active
interface lag2 {
}
df-election {
timers {
activation-timer 0
}
algorithm {
type default
}
}
}
}
}
}
bgp-vpn {
bgp-instance 1 {
}
}
}
}
}
before:
data: |-
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/4 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/5 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/6 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/7 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/8 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/9 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/10 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag1
lacp-port-priority 32768
}
}
interface ethernet-1/11 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag1
lacp-port-priority 32768
}
}
interface ethernet-1/12 {
description lag-leaf1-2-e1212-local
admin-state enable
ethernet {
aggregate-id lag2
lacp-port-priority 32768
}
}
interface lag1 {
description lag-leaf1-e1011-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 2
system-id-mac FE:2F:AA:00:00:02
system-priority 32768
}
}
}
interface lag2 {
description lag-leaf1-2-e1212-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 3
system-id-mac FE:2F:AA:00:00:03
system-priority 32768
}
}
}
interface mgmt0 {
admin-state enable
subinterface 0 {
admin-state enable
ipv4 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
ipv6 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
}
}
network-instance mgmt {
type ip-vrf
admin-state enable
description "Management network instance"
interface mgmt0.0 {
}
protocols {
linux {
import-routes true
export-routes true
}
}
}
system {
aaa {
authentication {
authentication-method [
local
]
admin-user {
password $aes1$ATetY3KV3PlLMW8=$tdr4AZSOUoHYR+Oatw6w4g==
}
}
authorization {
role sudo {
superuser true
services [
cli
gnmi
gnoi
gnsi
netconf
]
}
}
server-group local {
type local
}
}
ssh-server mgmt {
admin-state enable
network-instance mgmt
}
boot {
autoboot {
admin-state disable
}
}
configuration {
role sudo {
}
}
grpc-server mgmt {
admin-state enable
rate-limit 65535
session-limit 1024
metadata-authentication true
tls-profile EDA
network-instance mgmt
port 57400
services [
gnmi
gnoi
gnsi
]
gnmi {
commit-save false
}
}
lldp {
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
}
interface ethernet-1/4 {
admin-state enable
}
interface ethernet-1/5 {
admin-state enable
}
interface ethernet-1/6 {
admin-state enable
}
interface ethernet-1/7 {
admin-state enable
}
interface ethernet-1/8 {
admin-state enable
}
interface ethernet-1/9 {
admin-state enable
}
interface ethernet-1/10 {
admin-state enable
}
interface ethernet-1/11 {
admin-state enable
}
interface ethernet-1/12 {
admin-state enable
}
}
banner {
login-banner "This is a demo banner provisioned by Ansible on leafs"
}
name {
host-name leaf1
}
network-instance {
protocols {
evpn {
ethernet-segments {
bgp-instance 1 {
ethernet-segment lag-leaf1-2-e1212-local {
admin-state enable
esi 00:FE:2F:AA:00:00:03:00:00:00
multi-homing-mode all-active
interface lag2 {
}
df-election {
timers {
activation-timer 0
}
algorithm {
type default
}
}
}
}
}
}
bgp-vpn {
bgp-instance 1 {
}
}
}
}
}
dataUnavailable: false
format: text
status: 200
This output, however, is only friendly to machines, as the diff itself is not calculated, and most likely an operator would want to see the diff result in a way like the NOS displays it. With the added and removed lines.
A separate module - nokia.eda_utils_v1.transaction_diff - in the utils collections is provided to display the human-friendly diff for the node configuration and/or resources.
- name: Get Node Diff
hosts: all
gather_facts: false
vars:
tx_id: 60
node: leaf1
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
register: token
- name: Get node diff
nokia.eda_utils_v1.transaction_diff:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
transactionId: "{{ tx_id }}"
nodes:
- name: "*"
namespace: "*"
resources:
- name: "*"
gvk: "*"
namespace: "*"
register: response
- name: print var
ansible.builtin.debug:
var: response
response:
changed: false
failed: false
nodes:
- diff:
"Configuration Diff for leaf1 (- removed, + added):": |-
--- before
+++ after
@@ -224,9 +224,6 @@
interface ethernet-1/12 {
admin-state enable
}
- }
- banner {
- login-banner "This is a demo banner provisioned by Ansible on leafs"
}
name {
host-name leaf1
name: leaf1
namespace: eda
- diff:
"Configuration Diff for leaf2 (- removed, + added):": |-
--- before
+++ after
@@ -224,9 +224,6 @@
interface ethernet-1/12 {
admin-state enable
}
- }
- banner {
- login-banner "This is a demo banner provisioned by Ansible on leafs"
}
name {
host-name leaf2
name: leaf2
namespace: eda
resources:
- diff:
"Configuration Diff for banner-demo-leaf-banner-leaf1 (- removed, + added):":
|-
--- before
+++ after
@@ -1,12 +0,0 @@
-apiVersion: core.eda.nokia.com/v1
-kind: NodeConfig
-metadata:
- name: banner-demo-leaf-banner-leaf1
- namespace: eda
-spec:
- configs:
- - config: '{"login-banner": "This is a demo banner provisioned by Ansible on leafs"}'
- operation: Create
- path: .system.banner
- node-endpoint: leaf1
- priority: 0
gvk: NodeConfig.v1.core.eda.nokia.com
name: banner-demo-leaf-banner-leaf1
namespace: eda
- diff:
"Configuration Diff for banner-demo-leaf-banner-leaf2 (- removed, + added):":
|-
--- before
+++ after
@@ -1,12 +0,0 @@
-apiVersion: core.eda.nokia.com/v1
-kind: NodeConfig
-metadata:
- name: banner-demo-leaf-banner-leaf2
- namespace: eda
-spec:
- configs:
- - config: '{"login-banner": "This is a demo banner provisioned by Ansible on leafs"}'
- operation: Create
- path: .system.banner
- node-endpoint: leaf2
- priority: 0
gvk: NodeConfig.v1.core.eda.nokia.com
name: banner-demo-leaf-banner-leaf2
namespace: eda
- diff:
"Configuration Diff for demo-leaf-banner (- removed, + added):": |-
--- before
+++ after
@@ -1,11 +0,0 @@
-apiVersion: siteinfo.eda.nokia.com/v1alpha1
-kind: Banner
-metadata:
- labels:
- some-label: ansible-demo
- name: demo-leaf-banner
- namespace: eda
-spec:
- loginBanner: This is a demo banner provisioned by Ansible on leafs
- nodeSelector:
- - eda.nokia.com/role=leaf
gvk: Banner.v1alpha1.siteinfo.eda.nokia.com
name: demo-leaf-banner
namespace: eda
- diff:
"Configuration Diff for demo-leaf-banner (- removed, + added):": |-
--- before
+++ after
@@ -1,9 +0,0 @@
-apiVersion: siteinfo.eda.nokia.com/v1alpha1
-kind: BannerState
-metadata:
- name: demo-leaf-banner
- namespace: eda
-spec:
- nodes:
- - leaf1
- - leaf2
gvk: BannerState.v1alpha1.siteinfo.eda.nokia.com
name: demo-leaf-banner
namespace: eda
If the node configuration diffs are required for only specific nodes, their names can be provided instead of a wildcard:
Evidently, the diff confirms that the login banner will be removed if we were to proceed with the transaction.
Revert#
Should you find yourself in a situation where a rolled out changed brought more bad than good, you can revert the entire transaction. Let's revert the transaction that added two banner resources, this was done in transaction with ID 83.
- name: Revert Transaction
hosts: all
gather_facts: false
vars:
tx_id: 60
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Revert transaction
nokia.eda_core_v1.transaction.v2.revert:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
transactionId: "{{ tx_id }}"
register: response
- name: print var
ansible.builtin.debug:
var: response
The revert of a transaction results in a new transaction that negates the actions that were taken in the transaction referred by its ID.
Restore#
If thing were great 2, 20 or 200 transactions ago you should have a chance to restore the system to that state. The Git-powered time machine that EDA provides allows you to easily revert to a previous state no matter where you are.
Just a moment ago we recorded a transaction 85 where we reverted things, but let's say we want to go back to transaction 77. Easy:
Run by providing the desired transaction ID:
- name: Revert Transaction
hosts: all
gather_facts: false
vars:
tx_id: 60
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Revert transaction
nokia.eda_core_v1.transaction.v2.revert:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
transactionId: "{{ tx_id }}"
register: response
- name: print var
ansible.builtin.debug:
var: response
System information#
EDA version#
- name: Get EDA version
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get EDA version
nokia.eda_core_v1.about.version:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
state: query
register: response
- name: print var
ansible.builtin.debug:
var: response
EDA health#
- name: Get EDA health
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get EDA health
nokia.eda_core_v1.about.health:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
state: query
register: response
- name: print var
ansible.builtin.debug:
var: response
Users#
Get users#
The examples show how to retrieve all users of the platform as well as a named user.
- name: Get all and a specific user
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get all users
nokia.eda_core_v1.admin.users.users:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
state: query
register: users
- name: print var
ansible.builtin.debug:
var: users
- name: Get admin user
nokia.eda_core_v1.admin.users.users:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
username: admin
state: query
register: admin_user
- name: print var
ansible.builtin.debug:
var: admin_user
users:
changed: false
failed: false
result:
- enabled: true
firstName: EDA
groups:
- 5aefa9bb-6459-491e-994a-794c9a04a6e3
lastName: admin user
status:
lastSuccessfulLogin: "2025-08-24T14:56:15Z"
username: admin
uuid: f2a75035-56a5-4ba0-be9b-53e1351259be
- email: [email protected]
enabled: false
firstName: John
lastName: Wick
status: {}
username: new-user
uuid: bbd43cb1-4688-4952-ac22-f67c05a7fff2
status: 200
admin_user:
changed: false
failed: false
result:
- enabled: true
firstName: EDA
groups:
- 5aefa9bb-6459-491e-994a-794c9a04a6e3
lastName: admin user
status:
lastSuccessfulLogin: "2025-08-24T14:56:15Z"
username: admin
uuid: f2a75035-56a5-4ba0-be9b-53e1351259be
status: 200
Create user#
When creating the user, its group and password should be set separately after the user creation.
- name: Create user
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Create a new user
nokia.eda_core_v1.admin.users.users:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
username: new-user
firstName: John
lastName: Wick
email: [email protected]
state: present
register: response
- name: print var
ansible.builtin.debug:
var: response
response:
changed: true
failed: false
result:
email: [email protected]
enabled: false
firstName: John
lastName: Wick
status: {}
username: new-user
uuid: bbd43cb1-4688-4952-ac22-f67c05a7fff2
status: 201
Reset password#
To set the password of a newly created user or resetting a password of an existing user.
- name: Reset password for the user
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get user
nokia.eda_core_v1.admin.users.users:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
username: new-user
state: query
register: new_user
- name: print var
ansible.builtin.debug:
var: new_user
- name: Reset password
nokia.eda_core_v1.admin.users.resetpassword:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
uuid: "{{ new_user.result[0].uuid }}"
temporary: false
value: pass123
register: reset_request
- name: print var
ansible.builtin.debug:
var: reset_request
Node configs#
Get node configuration in the format that EDA uses to provision the nodes. Currently either native CLI or Openconfig.
- name: Get node config
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Get node config
nokia.eda_core_v1.nodeconfig.v2.namespaces.nodes:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
nsName: eda
nodeName: leaf1
state: query
register: response
- name: print var
ansible.builtin.debug:
var: response
The output contains the config annotations in the .result.annotations list and the running config in the .result.running block.
response:
changed: false
failed: false
result:
annotations:
- cr:
gvk:
group: bootstrap.eda.nokia.com
kind: Init
version: v1alpha1
name: init-base
lines:
- endLine: 141
startLine: 97
- endLine: 145
startLine: 145
- endLine: 170
startLine: 158
- endLine: 192
startLine: 175
- endLine: 235
startLine: 232
- endLine: 265
startLine: 265
- cr:
gvk:
group: bootstrap.eda.nokia.com
kind: ManagementRouter
version: v1alpha1
name: mgmt-router
lines:
- endLine: 125
startLine: 123
- endLine: 135
startLine: 135
- cr:
gvk:
group: core.eda.nokia.com
kind: Manifest
version: v1
name: aaa.eda.nokia.com
lines:
- endLine: 144
startLine: 142
- endLine: 156
startLine: 147
- endLine: 174
startLine: 171
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: lag-leaf1-2-e1212-local
lines:
- endLine: 57
startLine: 50
- endLine: 78
startLine: 61
- endLine: 136
startLine: 136
- endLine: 228
startLine: 226
- endLine: 265
startLine: 236
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: lag-leaf1-e1011-local
lines:
- endLine: 49
startLine: 34
- endLine: 96
startLine: 79
- endLine: 225
startLine: 220
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-1
lines:
- endLine: 2
- endLine: 195
startLine: 193
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-14
lines:
- endLine: 60
startLine: 58
- endLine: 231
startLine: 229
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-2
lines:
- endLine: 5
startLine: 3
- endLine: 198
startLine: 196
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-3
lines:
- endLine: 9
startLine: 6
- endLine: 201
startLine: 199
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-4
lines:
- endLine: 13
startLine: 10
- endLine: 204
startLine: 202
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-5
lines:
- endLine: 17
startLine: 14
- endLine: 207
startLine: 205
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-6
lines:
- endLine: 21
startLine: 18
- endLine: 210
startLine: 208
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-7
lines:
- endLine: 25
startLine: 22
- endLine: 213
startLine: 211
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-8
lines:
- endLine: 29
startLine: 26
- endLine: 216
startLine: 214
- cr:
gvk:
group: interfaces.eda.nokia.com
kind: Interface
version: v1alpha1
name: leaf1-ethernet-1-9
lines:
- endLine: 33
startLine: 30
- endLine: 219
startLine: 217
running: |-
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/4 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/5 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/6 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/7 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/8 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/9 {
admin-state enable
vlan-tagging true
}
interface ethernet-1/10 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag2
lacp-port-priority 32768
}
}
interface ethernet-1/11 {
description lag-leaf1-e1011-local
admin-state enable
ethernet {
aggregate-id lag2
lacp-port-priority 32768
}
}
interface ethernet-1/12 {
description lag-leaf1-2-e1212-local
admin-state enable
ethernet {
aggregate-id lag1
lacp-port-priority 32768
}
}
interface ethernet-1/14 {
admin-state enable
}
interface lag1 {
description lag-leaf1-2-e1212-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 1
system-id-mac FE:2F:AA:00:00:01
system-priority 32768
}
}
}
interface lag2 {
description lag-leaf1-e1011-local
admin-state enable
vlan-tagging true
lag {
lag-type lacp
min-links 1
lacp-fallback-mode static
lacp-fallback-timeout 60
lacp {
interval FAST
lacp-mode ACTIVE
admin-key 3
system-id-mac FE:2F:AA:00:00:03
system-priority 32768
}
}
}
interface mgmt0 {
admin-state enable
subinterface 0 {
admin-state enable
ipv4 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
ipv6 {
admin-state enable
dhcp-client {
trace-options {
trace [
messages
]
}
}
}
}
}
network-instance mgmt {
type ip-vrf
admin-state enable
description "Management network instance"
interface mgmt0.0 {
}
protocols {
linux {
import-routes true
export-routes true
}
}
}
system {
aaa {
authentication {
authentication-method [
local
]
admin-user {
password $aes1$ATfFb4Am95W8pW8=$eOQ5tWPh1Whx7GovYXvUUA==
}
}
authorization {
role sudo {
superuser true
services [
cli
gnmi
gnoi
gnsi
netconf
]
}
}
server-group local {
type local
}
}
ssh-server mgmt {
admin-state enable
network-instance mgmt
}
boot {
autoboot {
admin-state enable
}
}
configuration {
role sudo {
}
}
grpc-server mgmt {
admin-state enable
rate-limit 65535
session-limit 1024
metadata-authentication true
tls-profile EDA
network-instance mgmt
port 57400
services [
gnmi
gnoi
gnsi
]
gnmi {
commit-save false
}
}
lldp {
interface ethernet-1/1 {
admin-state enable
}
interface ethernet-1/2 {
admin-state enable
}
interface ethernet-1/3 {
admin-state enable
}
interface ethernet-1/4 {
admin-state enable
}
interface ethernet-1/5 {
admin-state enable
}
interface ethernet-1/6 {
admin-state enable
}
interface ethernet-1/7 {
admin-state enable
}
interface ethernet-1/8 {
admin-state enable
}
interface ethernet-1/9 {
admin-state enable
}
interface ethernet-1/10 {
admin-state enable
}
interface ethernet-1/11 {
admin-state enable
}
interface ethernet-1/12 {
admin-state enable
}
interface ethernet-1/14 {
admin-state enable
}
}
name {
host-name leaf1
}
network-instance {
protocols {
evpn {
ethernet-segments {
bgp-instance 1 {
ethernet-segment lag-leaf1-2-e1212-local {
admin-state enable
esi 00:FE:2F:AA:00:00:01:00:00:00
multi-homing-mode all-active
interface lag1 {
}
df-election {
timers {
activation-timer 0
}
algorithm {
type default
}
}
}
}
}
}
bgp-vpn {
bgp-instance 1 {
}
}
}
}
}
status: 200
Database access#
EDA's distributed sharded database, or EDB for short, stores all the state available to the platform in memory. The nokia.eda_core_v1.db.v2.data module allows users to query the EDB tables and fetch the data stored there.
To query the EDB table a user needs to provide the EDB path in the form of a JSPath. In the example below we query the .namespace.node.srl.system.information table that contains the system information for all SR Linux nodes onboarded in EDA.
- name: Run EQL Query
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Fetch EDB table
nokia.eda_core_v1.db.v2.data:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
includeKeys: true
jsPath: .namespace.node.srl.system.information
register: response
- name: print var
ansible.builtin.debug:
var: response
response:
changed: false
failed: false
result:
.namespace{.name=="eda"}.node{.name=="leaf1"}.srl.system.information:
.namespace.name: eda
.namespace.node.name: leaf1
current-datetime: "2025-11-07T13:16:06.388Z"
description: "SRLinux-v25.7.2-266-g3bfa66eadcd 7220 IXR-D3L Copyright
(c) 2000-2025 Nokia. Kernel 6.1.0-37-cloud-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.140-1 (2025-05-22)"
last-booted: "2025-11-06T13:10:37.397Z"
version: v25.7.2-266-g3bfa66eadcd
.namespace{.name=="eda"}.node{.name=="leaf2"}.srl.system.information:
.namespace.name: eda
.namespace.node.name: leaf2
current-datetime: "2025-11-07T13:16:06.583Z"
description: "SRLinux-v25.7.2-266-g3bfa66eadcd 7220 IXR-D3L Copyright
(c) 2000-2025 Nokia. Kernel 6.1.0-37-cloud-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.140-1 (2025-05-22)"
last-booted: "2025-11-06T13:10:37.382Z"
version: v25.7.2-266-g3bfa66eadcd
.namespace{.name=="eda"}.node{.name=="spine1"}.srl.system.information:
.namespace.name: eda
.namespace.node.name: spine1
current-datetime: "2025-11-07T13:16:06.501Z"
description: "SRLinux-v25.7.2-266-g3bfa66eadcd 7220 IXR-D5 Copyright (c)
2000-2025 Nokia. Kernel 6.1.0-37-cloud-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.140-1 (2025-05-22)"
last-booted: "2025-11-06T13:10:38.134Z"
version: v25.7.2-266-g3bfa66eadcd
status: 200
The returned data is schema-less, as in the result does not explain the structure of the returned objects. To understand the schema for a particular EDB table, you can use the nokia.eda_core_v1.db.v2.schema module to fetch the table schema:
- name: Run EQL Query
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Fetch EDB table schema
nokia.eda_core_v1.db.v2.schema:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
tlsSkipVerify: "{{ tls_skip_verify }}"
tableName: .namespace.node.srl.system.information
register: response
- name: print var
ansible.builtin.debug:
var: response
response:
changed: false
failed: false
result:
description: Top-level container for system information configuration and
state
properties:
contact:
description: |-
The system contact
This field represents contact information for the person or group that maintains the system. This field is exposed via SNMP at the sysContact OID.
type: string
current-datetime:
description: The current system date and time
format: date-time
readOnly: true
type: string
description:
description: |-
The system description
This field is system generated, and is a combination of the system host name, software version, kernel version, and build date. The template for this field is: SRLinux-<version> <hostname> <kernel> <build date>. This field is exposed via SNMP at the sysDescr OID.
readOnly: true
type: string
last-booted:
description: The date and time the system was last booted
format: date-time
readOnly: true
type: string
location:
description: |-
The system location
This field represents the location of the system, and is commonly used by inventory management systems to group elements together. This field is exposed via SNMP at the sysLocation OID.
type: string
protobuf-metadata:
description: |-
A binary marshalled protobuf message, with a size that does not exceed
1MiB containing metadata related to the element of the data tree at which
the metadata annotation is used.
It is expected that this metadata can be both written and read by a
client - and that the value is persistent across system restarts.
A client using this metadata extension should ensure that it is able
to unmarshal its contents successfully. It is suggested that the
payload should be a protobuf.Any message, which has corresponding
type information such that information as to the intended structure
can be retrieved by any reader.
type: string
version:
description: |-
The system version
This field represents the version of the management server
readOnly: true
type: string
type: object
x-eda-nokia-com:
properties:
children:
- coordinates
keys:
properties:
.namespace.name:
type: string
.namespace.node.name:
type: string
type: object
type: object
status: 200
In contrast with EDA Queries (EQL), EDB access is not limited by 1000 records and returns all matching records without paging. EDB access does not, though, support the EQL syntax, but supports fields selection and
wherefiltering.
EDA Queries#
To execute an EQL query in a non-streaming mode, use the nokia.eda_core_v1.query.v1.eql.eql module:
- name: Run EQL Query
hosts: all
gather_facts: false
tasks:
- name: Fetch EDA access token
nokia.eda_utils_v1.get_token:
baseUrl: "{{ eda_api_url }}"
clientSecret: "{{ client_secret }}"
username: admin
password: "{{ eda_password }}"
register: token
- name: Run a query
nokia.eda_core_v1.query.v1.eql.eql:
baseUrl: "{{ eda_api_url }}"
authToken: "Bearer {{ token.result.access_token }}"
query: .namespace.node.srl
namespaces: eda
register: response
- name: print var
ansible.builtin.debug:
var: response
response:
changed: false
failed: false
result:
data:
- .namespace.name: eda
.namespace.node.name: leaf1
version: 25.3.2
- .namespace.name: eda
.namespace.node.name: leaf2
version: 25.3.2
- .namespace.name: eda
.namespace.node.name: spine1
version: 25.3.2
jsonSchema:
properties:
.namespace.name:
type: string
x-eda-nokia-com:
ui-order-priority: 1
.namespace.node.name:
type: string
x-eda-nokia-com:
ui-order-priority: 2
version:
type: string
type: object
x-eda-nokia-com:
properties:
keys:
properties:
.namespace.name:
type: string
.namespace.node.name:
type: string
type: object
type: object
schema:
fields:
- annotations:
- end_char: 8
start_char: 0
- end_char: 13
start_char: 10
display_name: namespace.name
name: .namespace.name
type: string
- annotations:
- end_char: 3
start_char: 0
- end_char: 8
start_char: 5
display_name: node.name
name: .namespace.node.name
type: string
- annotations:
- end_char: 6
start_char: 0
display_name: version
name: version
type: string
status: 200
In the response, you will find the list of returned objects under the .result.data key. The elements of this list would match what you would see in the table when running EQL in EDA UI.
In addition to the actual values, the response will include the schema for the returned objects, such is their types and structure.
EQL queries API only returns maximum of 1000 records. To retrieve more records use the Database access modules.
Changelog v1#
1.0.0#
Initial release.
0.2.0#
- Add documentation for the top level collection fields
- Update modules for workflows and resource lists
0.1.0#
Initial Beta release.
-
Later we will have a module in the util collection that will allow you performing the diff easily. ↩