We want to refactor the build / deploy / testing of Fluence so that:
it uses kubernetes-sigs/scheduler-plugins directly
a rebase / update is done once a week against upstream:
The rebuilt plugin is tested, ensuring we can create the example pod, and it is scheduled and runs
Likely we want a pod that outputs something meaningful to check
Successful testing -> deploy updated containers, ensuring a version of fluence with latest upstream is always available
We will likely maintain this as latest, along with tags for versions of kube-scheduler, and dated tags
Specific design notes for the refactor, we are aiming for a structure like this:
sig-scheduler-plugins/ <-- references kubernetes-sigs/scheduler-plugins clearly
manifests/fluence
pkg/fluence
...
src/ <-- the current scheduler-plugin source code (will be renamed after with PR)
High level, we will keep here only the files here that need to be added (for build) to the upstream, and then in the CI, run and test that build, and deploy on success. I'm assigning myself to this issue because (after the first commit of the files from our psap-openshift fork) I should be oriented to handle the above work. When this issue I will go through other issues still open, either following up with people or closing (if the work is done).
We want to refactor the build / deploy / testing of Fluence so that:
Specific design notes for the refactor, we are aiming for a structure like this:
High level, we will keep here only the files here that need to be added (for build) to the upstream, and then in the CI, run and test that build, and deploy on success. I'm assigning myself to this issue because (after the first commit of the files from our psap-openshift fork) I should be oriented to handle the above work. When this issue I will go through other issues still open, either following up with people or closing (if the work is done).