Update how-it-works.md
This commit is contained in:
parent
2ce69f9394
commit
5164fbc3e4
|
|
@ -24,7 +24,19 @@ User reconciliation loop takes care of reconciling user provided configuration,
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## Operator Status
|
## Operator State
|
||||||
|
|
||||||
Operator status is used for storing any configuration events or job statuses managed by the operator.
|
Operator state is kept in custom resource status section, which is used for storing any configuration events or job statuses managed by the operator.
|
||||||
It helps to maintain or recover desired state even after operator or Jenkins restarts.
|
It helps to maintain or recover desired state even after operator or Jenkins restarts.
|
||||||
|
|
||||||
|
## System Jenkins Jobs
|
||||||
|
|
||||||
|
The operator or Jenkins instance can be restarted at any time and any operation should not block the reconciliation loop so we implemented
|
||||||
|
custom jobs API for executing and verifying status of them according to operator lifecycle.
|
||||||
|
|
||||||
|
Main assumptions are:
|
||||||
|
- do not block reconciliation loop
|
||||||
|
- fire job, requeue reconciliation loop and verify status next time
|
||||||
|
- handle retries if case of failure
|
||||||
|
- handle build expiration (deadline)
|
||||||
|
- keep state in the custom resource status
|
||||||
Loading…
Reference in New Issue