canonical / bundle-kubeflow

Charmed Kubeflow
Apache License 2.0
104 stars 50 forks source link

Create a Profiles Automator charm #1142

Open kimwnasptd opened 1 week ago

kimwnasptd commented 1 week ago

Context

As part of our whole Profile creation automation objective we want as a first step to ensure we have a charm that:

  1. Take a Profiles Management Representation (PMR) input, via a relation
  2. Update/Remove
    • Profiles in the cluster, to reflect the PMR
    • AuthorizationPolicies/RoleBindings

The charm should then be related to integrator charms that will be responsible for looking at different sources (GitHub, PingID, EntraID etc) and converting them to PMR.

What needs to get done

  1. https://github.com/canonical/bundle-kubeflow/issues/1143
    1. the edge cases of the charm, how to add/remove Profiles and AuthorizationPolicies/ClusterRolebindings
    2. the structure of the PMR
    3. what the library for passing the data between charms should work
  2. https://github.com/canonical/bundle-kubeflow/issues/1144
  3. Have a Profiles Automator charm, with integration tests
  4. Create the logic/charm for fetching Profiles info from GitHub

Definition of Done

  1. There is a new repo with descriptive README
  2. We have integration and unit tests for the charm and the library
  3. Have an approved spec
syncronize-issues-to-jira[bot] commented 1 week ago

Thank you for reporting us your feedback!

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

This message was autogenerated

kimwnasptd commented 1 week ago

note that the design is initially started in the spec KF107. It initially had a design of having the Profile Automator logic in one charm and then plugging different source-integrator charms to it, to separate the logic of Profile management and fetching from different sources.

After a chat with @deusebio we are also evaluating his proposal of instead:

  1. Abstracting away the logic of updating the cluster state (Profiles) inside of a python (charm) library
  2. Having charms like github-profiles-automator and entraid-profiles-automator that handle the logic of talking to a source, but then use the same library for manipulating the cluster's state

We'll do a more thorough analysis of the above, with pros and cons, as part of finalising the above spec.