I am wondering what is the most “elegant” way to implement in a charm a kubernetes resource that is not supported by Juju’s pod_spec. For context, I am talking about charming with the operator framework. One idea would be to add in the charm a function that calls subprocess, to execute the manual command with kubectl. Any other ideas?
As for what type of resources that are not supported by pod_spec, one example is the Pod Security Policies. There is currently a bug opened for this (Bug #1886694 “Podspec for k8s charm does not support Pod Securit...” : Bugs : juju), and I am not expecting to see it included in the pod spec until the next release. However, if I have to charm an application that requires it, I am stuck. This is an example of a manifest for a Pod Security Policy :
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: labels: app: metallb name: controller namespace: metallb-system spec: allowPrivilegeEscalation: false allowedCapabilities:  allowedHostPaths:  defaultAddCapabilities:  defaultAllowPrivilegeEscalation: false fsGroup: ranges: - max: 65535 min: 1 rule: MustRunAs hostIPC: false hostNetwork: false hostPID: false privileged: false readOnlyRootFilesystem: true requiredDropCapabilities: - ALL runAsUser: ranges: - max: 65535 min: 1 rule: MustRunAs seLinux: rule: RunAsAny supplementalGroups: ranges: - max: 65535 min: 1 rule: MustRunAs volumes: - configMap - secret - emptyDir
Thank you for the help!