kube-sig / koji-operator

#19 koij plugin support
Closed by lrossett. Opened by lrossett.

Closed
Reopen Issue

The operator needs to allow users to create configmaps and secrets touse them as koji plugins.

This could be accomplished by using specific labels so the operator can watch those resources and mount them into the pod.

It will probably need an annotation as well to identify which type of plugin it is (hub, builder, etc).

It could also be a custom resource, KojiPlugin, that refers a configmap to load (this way the custom resource will have the required metadata to load the plugin).

A way to implement this using a custom resource:

apiVersion: buildsys.apps.fedoraproject.org/v1alpha1
kind: KojiPlugin
metadata:
  name: myplugin
  annotations:
    buildsys.apps.fedoraproject.org/hub: sample/default # $NAME/$NAMESPACE
    buildsys.apps.fedoraproject.org/ctx: hub # hub, builder, etc
spec:
  configmap:
    name: hub-plugin
    namespace: default # uses the CR namespace if omitted

Same CR but using a secret instead:

apiVersion: buildsys.apps.fedoraproject.org/v1alpha1
kind: KojiPlugin
metadata:
  name: myplugin
  annotations:
    buildsys.apps.fedoraproject.org/hub: sample/default # $NAME/$NAMESPACE
    buildsys.apps.fedoraproject.org/ctx: hub # hub, builder, etc
spec:
  secret:
    name: hub-plugin
    namespace: default # uses the CR namespace if omitted

The configmap itself could be something like this (plugin.py is expected here):

apiVersion: v1
kind: ConfigMap
metadata:
  name: myplugin
data:
  plugin.py: |-
    print('hello from my plugin python code')
Edited by lrossett

Metadata Update from @lrossett:
- Issue tagged with: infra

Closing this issue as we tracking all SIG issues in a single repository: https://pagure.io/kube-sig/kube-sig/issues

Metadata Update from @lrossett:
- Issue status updated to: Closed (was: Open)
Metadata
None

dev infra

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.