You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are sending a lot of upate cr request to the API server because we are trying to update the reference of the child every time it reconciles. Most of the reconciles are happening with a state that adapter has not received all of its children. So we are sending a lot of update request to api server. While we have a lot of APIs preloaded in the cluster, api server becomes congested. So we have two options
Move the update logic to the last line of resolveApiRef method, only do a update reference if all the children are found and based on the apiState variable(It would have all the children). The problem with this approach is it will cause dangling CR problem in this scenario: I create api and bunch of resources but forgot to apply one of its child hence API is not resolved in the adapter side so no owner reference to any of the child of this API. Now I decides to delete the API instead of adding that missing child cr. Now we are left with dangling resources.
Move the update onwer reference logic to watch methods of each child object and do the update there.
I am going ahead with the option 2 as it does not have the dangling cr problem.
The text was updated successfully, but these errors were encountered:
Tharsanan1
changed the title
UpdateCR method IO wait throttles the overall performance
Adapter sends too many update requests to API server
Jan 12, 2024
While doing the development, I realized that we will be endup with dangling CR problem if we only go with option 1. So I have used a hybrid approach of option 1 and option 2 to solve this issue. PR: #1948
We are sending a lot of upate cr request to the API server because we are trying to update the reference of the child every time it reconciles. Most of the reconciles are happening with a state that adapter has not received all of its children. So we are sending a lot of update request to api server. While we have a lot of APIs preloaded in the cluster, api server becomes congested. So we have two options
Move the update logic to the last line of resolveApiRef method, only do a update reference if all the children are found and based on the apiState variable(It would have all the children). The problem with this approach is it will cause dangling CR problem in this scenario: I create api and bunch of resources but forgot to apply one of its child hence API is not resolved in the adapter side so no owner reference to any of the child of this API. Now I decides to delete the API instead of adding that missing child cr. Now we are left with dangling resources.
Move the update onwer reference logic to watch methods of each child object and do the update there.
I am going ahead with the option 2 as it does not have the dangling cr problem.
The text was updated successfully, but these errors were encountered: