Create a Profiles Automator charm

[kimwnasptd]

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. Create a spec for the high level architecture of the Profiles Automator charm #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. Create the common library for Profiles Automator charm(s) github-profiles-automator#8
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]

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]

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.