feat: support pods that are owned by deployments

[cgetzen]

Summary

Resolves #21

The deployment example in https://github.com/SlinkyProject/slurm-bridge/blob/main/docs/workload.md#annotations does not work.

Given that Pod is a supported workload, pods owned by deployments should also be supported.

Checklist

• I have read
  CONTRIBUTING.md
  and the
  Code of Conduct.
• New or existing tests cover these changes (where applicable).
• Documentation is updated if user-visible behavior changes.

Breaking Changes

No breaking changes

Testing Notes

Integration tests have been added for the scheduler, similar to controller and admissions integration tests.

Applying the example from the readme now schedules correctly:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pause
  # `slurm-bridge` annotations on parent object
  annotations:
    slinky.slurm.net/timelimit: "5"
    slinky.slurm.net/account: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pause
  template:
    metadata:
      labels:
        app: pause
    spec:
      schedulerName: slurm-bridge-scheduler
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.6
          resources:
            limits:
              cpu: "1"
              memory: 100Mi

Additional Context

[vivian-hafener]

Good morning @cgetzen,

Despite the example in the documentation, at this time Slurm-bridge does not support the scheduling of Deployments. I am tracking an issue internally to enable this capability, though it will take some time, as it will require changes to Slurm itself. In the meantime, I will try to get that example in the docs fixed.

Best,
Vivian Hafener

[cgetzen]

Appreciate the review.

We've been scheduling Deployments' pods for a few months (though we've granted permissions by creating additional clusterRoles and clusterRoleBindings instead of changing the chart, in order reduce divergence from upstream) and have not encountered issues related to pods being owned by Deployments.

I will be looking out for the changes in slurm to see what we missed. Thanks!

[cgetzen]

It may be worth considering how slurm-bridge handles 3rd party pod controllers. Right now, my org is adding arbitrary permissions like:

- apiGroups: ["apps.kruise.io"]
  resources: ["clonesets"]
  verbs: ["get", "list", "watch"]

Maybe slurm-bridge should still schedule pods even when it doesn't have permission to walk the ownership tree.