Proposal: Using Finite State Machine library to expose state diagram for configuration applied transitions

[edcdavid]

Proposing to use https://github.com/qmuntal/stateless to expose the implicit state diagram used for The configuration applied status

• With each calls to reconcile, the state machine is initialized with the current state saved in configurationAppliedCondition.Reason
• The FsmHelper collects all the data required by the state machine to make its transition decisions. It is initialized during reconciliation with .InitFromCluster()
• updateConfigurationAppliedStatus pushes updates to the status back to the cluster

The fsm_test.go tests the state machine transitions independently from kubenetes.
The ci-job process updates the state diagram in documentation (dev/config_fsm.mg link)

TODO:

• Unit tests
• add CGO in prow for creating SVG in docs
• system test - retesting

[edcdavid]

/cc @irinamihai @Missxiaoguo

[Missxiaoguo]

/lgtm

[pixelsoccupied]

Although it's a nice use of fsm, i dont know if the concept of finite statement machine is compatible with the notion of k8s controller? Meaning operators are meant to be "level based", i.e look at the state of the cluster at every requeue until we reach desired state vs "edge-based" where we are relying to history stored in status.

Api convention doc specifically says .status should not be used for state machines.

lots of great doc on this:

• https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
• https://book.kubebuilder.io

Since this is totally new pattern we are introducing (I couldnt find any reference of fsm lib in operators anywhere), at the very least this should be better documented for anyone coming to develop this in the future?

[pixelsoccupied]

Would it be possible generate this using make generate by sm.ToGraph() as mentioned here

Also since this generated...would it be nicer to move this under say docs/generated/clusterrequest-fsm to reflect the content better?

[openshift-ci]

New changes are detected. LGTM label has been removed.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from missxiaoguo. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-merge-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[edcdavid]

Closing this PR for now, does not follow the no state/machine recommendation for operator. Should recompute the state from information available in the cluster. This follow up PR is attempting to do this: #246