Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a spec for the high level architecture of the Profiles Automator charm #1143

Open
kimwnasptd opened this issue Nov 5, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@kimwnasptd
Copy link
Contributor

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:

  1. If we should have a dedicated Profile Automator, and multiple source-integration charms
  2. What the common code/library should be doing
    1. Should it be abstracting the logic of creating Profiles?
    2. 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

  1. Write down pros/cons of having github-profiles-automator charm vs github-automator + github-profiles-ir charms
  2. Write down what the common library should be doing in both cases, with step by step examples
  3. Have a sync and make the decision on the final architecture, based on the guidance of the decision maker
  4. Update the spec

Definition of Done

  1. The spec is approved
  2. We can start working on the logic for both the GitHub source logic and the Profiles Automator
@kimwnasptd kimwnasptd added the enhancement New feature or request label Nov 5, 2024
Copy link

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-6532.

This message was autogenerated

@kimwnasptd
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant