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
Context
This is sub-step for https://github.com/canonical/bundle-kubeflow/issues/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