Hi @andreaTP,

thanks for the fast response and answers. I created the corresponding issue for the documentation: #12725.

The biggest drawback of this approach is that we completely lose the validation performed by Kubernetes that is "expected" when it comes to "cloud native" resources.

I totally understand where this is coming from. But I see a conflicting UX here. Even with an enhanced level of supported nesting, I cannot be really assured that my valid export can be imported. There is the additional problem, that the operator itself seems to not report any warnings or errors when the file gets actually converted into the restricted form (this can be enhanced of course).

In the worst case I have to manually duplicate the otherwise nicely implemented job structure for the import, but with a custom provided file, to get it working.

Another thing maybe worth considering:
I tried to import a rather small realm (around 8000 lines in the yaml format). But will this kind of workflow not run into the limitations for the size of CR objects? I remember, that e.g. the controller-runtime project had similar discussions regarding that. Especially since the data will be replicated in the last-applied annotation?

So when I understand it correctly, the goal is here to get validation at the kubectl apply step when using the import CR.

My personal opinion here is, that a referenced file from a secret/configmap with internal validation and a good status update in the import CR in the cluster provides a similar good UX. Actually, I was kinda expecting that the conditions in the import CR report more than just a simple "import failed" for this case.

This would also avoid the conversion step of json -> yaml -> json (by the operator), which seems kinda unnecessary when I just want to provide the exported file I just generated.

@mpreu thanks for this feedback, indeed very interesting points, let me answer one by one.

There is the additional problem, that the operator itself seems to not report any warnings or errors when the file gets actually converted into the restricted form (this can be enhanced of course).

This is surprising and it should be filed as a bug if you can reproduce it, a CR with an unsupported level of nesting should be rejected by Kubernetes itself when validated (e.g. you should be not able to upload it without explicitly disabling the validation).

But will this kind of workflow not run into the limitations for the size of CR objects?

I haven't thought about it before, but yes, the same limitation applies.
On the bright side, last-applied makes little sense for this CR as it's backed by a job, and overwrite is disabled, so it's always safe to delete/re-create instead of updating.
Anyhow, you are rising a good point, thanks!

So when I understand it correctly, the goal is here to get validation at the kubectl apply step when using the import CR.

Correct

My personal opinion here is, that a referenced file from a secret/configmap with internal validation and a good status update in the import CR in the cluster provides a similar good UX. Actually, I was kinda expecting that the conditions in the import CR report more than just a simple "import failed" for this case.

Thanks for sharing, we are actually evaluating other use-cases I will make sure this option is taken into consideration.

This would also avoid the conversion step of json -> yaml -> json (by the operator), which seems kinda unnecessary when I just want to provide the exported file I just generated.

That's correct, I was thinking about implementing an export directly to yaml CRD (which is actually trivial).

Overall is completely possible to implement what you requested, and we can even evaluate to have it as an "alternative" to the current encoding (e.g. inline vs. external realm representation), the size limit, unfortunately, still applies as it's the same for secrets (1M) and we would need to allow mounting PV/PVC to overcome completely the limitation.