2-way reconciliation with external resources

[jbw976]

External resources (which is most everything Crossplane manages) should participate in a 2-way reconciliation where Crossplane's changes to external resources are honored by the external provider and external changes to that resource are honored by Crossplane.

There are some big questions to answer here such as where is the final authoritative state stored? How does Crossplane know it should a change should be honored as opposed to the resource has diverged from the desired state and should therefore take corrective action?

Related to #289 to receive notifications for when changes are made to external resources.

[jbw976]

Related to #9

[hasheddan]

These three issues (this one along with #289 and #9) are very interesting to me. I would love to help out with this sort of functionality! I imagine we will need to have a community discussion around this before moving forward. For the authoritative state portion, I would lean toward making Crossplane the authority for the reason that you mentioned around when to take corrective action.

There is always a balance between flexibility of a system and enforcement of good practices. Sometimes a feature (i.e. the ability to choose where state lives in this case) just creates more opportunity for policy violations.

The only reason I can see to potentially allow for state to be shared or in an entity other than Crossplane is to allow for a "fell swoop" full resource migration to Crossplane, followed by a slower migration of management of those resources. Once again though, part of the value proposition is centralized and automatic (i.e. reconciliation) state management of external resources, so I am not sure that we want to even allow for another option.

[negz]

I don't believe Crossplane should participate in "two way" reconciliation. Crossplane should consider the spec of its managed resources to be the authoritative desired state of their corresponding external resources, and should drive the state of those external resources toward the spec.

The one exception to this rule is "late initialisation", as described by the Kubernetes API conventions, which states that a controller may set unset spec fields. This allows for cases in which a managed resource spec field corresponds to an external resource API field that may be omitted, but is automatically set by the cloud provider when it is.

[negz]

Per my last comment here, I don't think we should do this. Please reopen if you disagree.