docs/proposal: submit konnector adopt#176
Conversation
|
|
||
| ## Proposed change | ||
|
|
||
| The Konnector adds an annotation `kube-bind.io/bound=true` to resources that have a counterpart in a consumer cluster. If the annotation is present and the consumer object is missing, the object in the provider cluster gets deleted. If the annotation is not present, and the object in the consumer cluster does not exist, but it does in the provider cluster, the konnector will create the resource in the consumer cluster, and add the annotation. |
There was a problem hiding this comment.
It seems a bit strange to me that an annotation has to be set on all adopted resources. Opt-in scenario seems more appealing.
| ## Adoption | ||
|
|
||
| What does adoption mean? Adoption means that a consumer cluster creates an object that exists on the provider cluster. Once the konnector creates the object in the consumer cluster, the consumer cluster controls the lifecycle of the object. | ||
| There are use cases in which the provider may want to create objects of an APIService before the consumer binds it to their cluster. These objects should be controlled by the consumer cluster, but may be created before the consumer cluster, and thus the konnector exists. Currently, the konnector will assume the objects have been deleted on the consumer cluster. The konnector will delete the objects. The desired behaviour would be that the Konnector recognizes the object has not existed on the consumer cluster, and to create it instead. |
There was a problem hiding this comment.
Wouldn’t this be just a case of claimed resources API, to specify the desired behavior on the consumer side missing?
There was a problem hiding this comment.
I think claimed resources could be used for it, thank you for that insight. It did not come to my mind. I'm wondering if it isn't overloading the API. We have a split between APIExport and claimed resources, adding types from the APIExport to claimed resources would dilute that separation.
One could swing the other way too. An APIExport could also be described as a claimed resource instead. It could be boiled down to a claim to create a CRD, read that CRDs objects spec, and claim updates on the status
2 participants
No description provided.