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'll need to have a spec that will document the design decisions and architecture of how to create the Profile Automator charm. The ongoing spec is KF107.
The architectural parts that will need more attention are:
If we should have a dedicated Profile Automator, and multiple source-integration charms
What the common code/library should be doing
Should it be abstracting the logic of creating Profiles?
Should it be abstracting the logic for representing profiles?
The goal of this is once we have the spec we can then start working on any common code needed and the charms that will take care of updating the Profiles from a GH repo source.
What needs to get done
Write down pros/cons of having github-profiles-automator charm vs github-automator + github-profiles-ir charms
Write down what the common library should be doing in both cases, with step by step examples
Have a sync and make the decision on the final architecture, based on the guidance of the decision maker
Update the spec
Definition of Done
The spec is approved
We can start working on the logic for both the GitHub source logic and the Profiles Automator
The text was updated successfully, but these errors were encountered:
One of the technical limitations we saw during the development of the spec was around how to update RoleBindings.
More specifically, K8s does not allow us to update a RoleBindings and the roleRef:
The RoleBinding "kimonas-contributor" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"kubeflow-edit"}: cannot change roleRef
This will mean that we can't rely on updating the RoleBinding resources, but the code will need to delete one and then re-apply it if the RoleBinding needs to be updated.
Context
This is sub-step for #1142
We'll need to have a spec that will document the design decisions and architecture of how to create the Profile Automator charm. The ongoing spec is KF107.
The architectural parts that will need more attention are:
The goal of this is once we have the spec we can then start working on any common code needed and the charms that will take care of updating the Profiles from a GH repo source.
What needs to get done
github-profiles-automator
charm vsgithub-automator
+github-profiles-ir
charmsDefinition of Done
The text was updated successfully, but these errors were encountered: