When creating a pod, switching between config view and yaml view breaks the pod spec

[mantis-toboggan-md]

To reproduce:

1. Navigate to the pod creation page (/dashboard/c//explorer/pod/create)
2. Add a name, container name, and container image
3. Click 'Edit as YAML'

Result:
The pod now has spec.template.spec.containers defined instead of spec.containers and creation fails.

Additional Context
spec.template.spec.containers would be correct for a workload. There appear to be some shenanigans going on behind-the-scenes with pod creation/editing in order to use the same form as workloads.
https://github.com/rancher/dashboard/blob/master/shell/edit/workload/mixins/workload.js#L181-L202

[rak-phillip]

There appears to be quite a few issues with the "Edit as YAML" button for the Pod form. Most of these problems have to deal with design intricacies of incorporating a Workload (Pod) into a form primarily designed for Workload Resources (Deployments, ReplicaSet, StatefulSets, etc.) ¹.

Clicking "Edit as YAML" generates an invalid pod spec while both creating and editing a pod. This issue seems to trace back to the form's inception ². As mentioned in the issue description, the root cause lies in the form's expectation of data shaped as spec.template.spec instead of spec, but I don't think the change to resolve this will be as simple as modifying the workload mixin.

To address this problem in the form, we currently mutate the shape of spec just before saving, allowing the pod to save properly ³.

I'm considering several approaches to tackle this issue:

1. Mutate value in shell/edit/workload/index.vue

   • This can probably be achieved in the willSaveWorkload hook located under shell/edit/workload/mixins/workload.js
   • Doing this will have some knock-on effects, as mutating value will break existing form fields

2. Expose a Slot in CruResource for the YAML Editor

   • This can allow us to pass a sanitized copy of value directly to the yaml editor
   • It might expose some implementation details that aren't relevant to Pods

I'm not sold on either approach at the moment and I think this problem requires more thought and design before moving forward to fix it. I'll continue to investigate and will follow up with more details as I learn more.

Footnotes

1. https://kubernetes.io/docs/concepts/workloads/ ↩

2. https://github.com/rancher/dashboard/commit/35c51c7f47192251a47b5010ce25d43c0747bb86#diff-ac776780d70ceae4eafb989d0dcd9a13815410a801c040143e9f60492d7aeb4cR160-R162 ↩

3. https://github.com/rancher/dashboard/blob/master/shell/models/pod.js#L236-L248 ↩

[gaktive]

This will be a big thing to tackle since we should refactor how we handle pods.

[gaktive]

Also reported in #12938 so I'll close that and leave this in place but we should consider if a back port is feasible, mindful that earlier we thought this may be a substantial undertaking.