-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Currently kir has hardcoded instructions of which kinds it supports and where inside each's structure that the PodSpec could be found:
Lines 11 to 31 in 26fef45
| // GetPodSpec extracts the PodSpec from a Kubernetes object | |
| func GetPodSpec(obj interface{}) (*corev1.PodSpec, error) { | |
| switch resource := obj.(type) { | |
| case *corev1.Pod: | |
| return &resource.Spec, nil | |
| case *appsv1.Deployment: | |
| return &resource.Spec.Template.Spec, nil | |
| case *appsv1.DaemonSet: | |
| return &resource.Spec.Template.Spec, nil | |
| case *appsv1.ReplicaSet: | |
| return &resource.Spec.Template.Spec, nil | |
| case *appsv1.StatefulSet: | |
| return &resource.Spec.Template.Spec, nil | |
| case *batchv1.Job: | |
| return &resource.Spec.Template.Spec, nil | |
| case *batchv1.CronJob: | |
| return &resource.Spec.JobTemplate.Spec.Template.Spec, nil | |
| default: | |
| return nil, fmt.Errorf("object does not have a PodSpec") | |
| } | |
| } |
I'm imagining that it could be possible to "look for the PodSpec" in the YAML, and when it matches, extract the images from there.
Possible benefits could be:
- Less hardcoded kinds/structures.
- Easier to use with other (custom) resources that include a
PodSpec.
Possible drawbacks:
- Slower.
- Easier to get wrong.
- More brittle.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels