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
This came up from the discussion of the early implementation of the PMR library #17 (comment)
Right now the PMR functions, during create_or_update_profiles(), will remove all RoleBindings and AuthorizationPolicies in a stale Profile. This has the following performance implications
If there's no cache, so that the code efficiently gets the list of RoleBindings, then a request to fetch all RoleBindings will happen every time create_or_update_profiles() is called
The code will then iterate over all RoleBindings to filter the ones that are KFAM RoleBindings
The current architecture was done this way to ensure that if someone onboards the Profile Automator charm(s) to an existing cluster, in which an admin might be manually updating the RoleBindings with custom automation, the state can align with our design.
If a user though starts from a clean cluster, then there's no need to look at all RoleBindings and we could rely on the fact that only RoleBindings were created via the Profile Automator charm(s), thus we could only use the PMR to remove RoleBindings in stale Profiles.
What needs to get done
Re-evaluate once we start seeing performance issues
Iron out the edge cases of the execution path, when handling stale Profiles, if we would only use the PMR
Evaluate if we can
Remove the function list_contributor_rolebindings altogether
Parse the PMR and figure out which RoleBindings need to be deleted
Definition of Done
The code doesn't run list_contributor_rolebindings at all
The text was updated successfully, but these errors were encountered:
My main concern with the above is that when figuring out a Profile is stale, this means that it doesn't exist in the PMR at all.
So we couldn't use the PMR to know which RoleBindings / AuthorizationPolicies should be deleted, since the PMR doesn't include any information about this Profile.
An alternative though could be to figure out a more efficient way to ask for KFAM RoleBindings, by filtering with annotations via lightkube. The K8s API Server would still need to do a filtering, but at least the whole list of RoleBindings is not passed back and forth
Context
This came up from the discussion of the early implementation of the PMR library #17 (comment)
Right now the PMR functions, during
create_or_update_profiles()
, will remove all RoleBindings and AuthorizationPolicies in a stale Profile. This has the following performance implicationscreate_or_update_profiles()
is calledThe current architecture was done this way to ensure that if someone onboards the Profile Automator charm(s) to an existing cluster, in which an admin might be manually updating the RoleBindings with custom automation, the state can align with our design.
If a user though starts from a clean cluster, then there's no need to look at all RoleBindings and we could rely on the fact that only RoleBindings were created via the Profile Automator charm(s), thus we could only use the PMR to remove RoleBindings in stale Profiles.
What needs to get done
list_contributor_rolebindings
altogetherDefinition of Done
list_contributor_rolebindings
at allThe text was updated successfully, but these errors were encountered: