Skip to content

Commit 8f8c0d0

Browse files
committed
Move workbench docs
1 parent c9c1aad commit 8f8c0d0

File tree

2 files changed

+158
-0
lines changed

2 files changed

+158
-0
lines changed

docs/images/flow_chart.png

25 KB
Loading

docs/operators.adoc

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
= Trento Agent Operators
2+
3+
An `+operator+` is a unit of code that can perform write operations on target machines.
4+
5+
Each operator knows how to execute actions and how to roll them back in
6+
case of failure.
7+
8+
== Operator
9+
10+
.flowchart
11+
image::./images/flow_chart.png[flowchart]
12+
13+
An operator is a unit of code that can perform write operations on
14+
target machines. +
15+
A write operation can either fail or succeed. If it succeeds, the
16+
operation displays a diff highlighting the changes before and after the
17+
commit phase.
18+
19+
The operator accepts arguments to specify how to perform the operations.
20+
The arguments are in the form of a `+map[string]any+`, and each operator
21+
knows how to extract and validate them. +
22+
It follows a transactional approach, where each operation has distinct
23+
stages:
24+
25+
* PLAN +
26+
* COMMIT +
27+
* VERIFY +
28+
* ROLLBACK
29+
30+
The documentation for each of the operators can be found in the
31+
operators go source.
32+
33+
=== PLAN
34+
35+
The goal of the PLAN stage is to collect information about the
36+
operations and verify prerequisites. +
37+
This is also the phase where information for diffing is gathered by
38+
collecting the `+before+` state.
39+
40+
Additionally, during this phase, it is important to ensure that any
41+
resources modified during the COMMIT phase are backed up. This allows
42+
restoration during the ROLLBACK phase or manual recovery by system
43+
administrators if the rollback fails.
44+
45+
If an error occurs during the PLAN phase, no rollback is needed; the
46+
operation is simply aborted with the plan error.
47+
48+
=== COMMIT
49+
50+
The COMMIT phase executes the actual write operations on the system,
51+
utilizing the information collected during the PLAN phase. +
52+
If an error occurs during this phase, a rollback is triggered.
53+
54+
The COMMIT phase should be idempotent. If a requested change has already
55+
been applied, the commit operation is simply skipped without returning
56+
an error. +
57+
Idempotency should be implemented appropriately based on the type of
58+
operations to be performed.
59+
60+
=== VERIFY
61+
62+
The VERIFY phase ensures that the actions applied during the COMMIT
63+
phase have produced the expected results on the system. +
64+
If an error occurs during this phase, the rollback process is initiated.
65+
66+
This phase is also when the `+after+` state is recorded for the diff,
67+
highlighting changes made during the commit phase.
68+
69+
=== ROLLBACK
70+
71+
The ROLLBACK phase must implement mechanisms to revert any changes made
72+
during the COMMIT phase. +
73+
It can use information collected during the PLAN phase to restore the
74+
system to its previous state. +
75+
The rollback implementation may vary depending on the type of operation
76+
performed during the COMMIT phase. +
77+
Be sure to provide clear error messages and log actions appropriately.
78+
79+
If the rollback fails, the error is returned without further action.
80+
81+
== Executor
82+
83+
The Executor is a wrapper around an operator. The operator implements
84+
the phase interface and must be wrapped in an Executor.
85+
86+
The Executor manages operations transactionally. +
87+
For library users, the Executor is transparent—using an Operator means
88+
it is already wrapped within an Executor.
89+
90+
== Registry
91+
92+
The Registry holds all available operators. Each operator has a version.
93+
By default, if no version is specified when requesting an operator, the
94+
latest version is fetched from the Registry.
95+
96+
To use an operator, it must be fetched using the `+GetOperatorBuilder+`
97+
function, providing the operator name as an argument.
98+
99+
[source,go]
100+
----
101+
builder, err := registry.GetOperatorBuilder(operatorName)
102+
op := builder("test-cli", opArgs)
103+
report := op.Run(ctx)
104+
// the report contains the success or the error of the execution
105+
----
106+
107+
The operator name follows this format: `+<operatorname>@<version>+`.
108+
109+
The Registry returns an Operator Builder:
110+
111+
[source,go]
112+
----
113+
type OperatorBuilder func(operationID string, arguments OperatorArguments) Operator
114+
----
115+
116+
The `+operationID+` is a unique identifier for the operation, and
117+
`+arguments+` are modeled as `+map[string]any+`.
118+
119+
== CLI
120+
121+
The operators execution is also exposed as a `+CLI+`. The functionality is
122+
hidden as it is intended only for testing and development purposes.
123+
124+
=== Usage
125+
126+
....
127+
Run operator
128+
129+
Usage:
130+
trento-agent operator run [flags]
131+
132+
Flags:
133+
-a, --arguments string The used operator arguments
134+
-h, --help help for run
135+
-o, --operator string The operator to use
136+
137+
....
138+
139+
The CLI accepts the name of an operator as an argument, following the
140+
same convention `+<operatorname>@<version>+`, and requires the `+-a+`
141+
option to pass the arguments.
142+
143+
The arguments must be provided as a JSON string.
144+
145+
=== Example
146+
147+
[source,bash]
148+
----
149+
sudo ./trento-agent operator run -o saptuneapplysolution -a '{"solution": "HANA"}'
150+
----
151+
152+
Using `+sudo+` may be necessary depending on the type of operator being
153+
executed. +
154+
In this example, the `+saptuneapplysolution+` operator is called with
155+
the argument `+solution+` set to `+HANA+`.
156+
157+
The CLI will perform the operations, log any errors, and finally display
158+
the diff when the execution succeeds.

0 commit comments

Comments
 (0)